Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1291437 > unrolled thread

[PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements

Started byAndy Lutomirski <luto@kernel.org>
First post2015-12-14 19:40 +0100
Last post2015-12-29 14:20 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements Andy Lutomirski <luto@kernel.org> - 2015-12-14 19:40 +0100
    [PATCH v2 2/6] mm: Add vm_insert_pfn_prot Andy Lutomirski <luto@kernel.org> - 2015-12-14 19:40 +0100
    [PATCH v2 4/6] x86,vdso: Use .fault for the vdso text mapping Andy Lutomirski <luto@kernel.org> - 2015-12-14 19:40 +0100
    [PATCH v2 3/6] x86/vdso: Track each mm's loaded vdso image as well as its base Andy Lutomirski <luto@kernel.org> - 2015-12-14 19:40 +0100
    Re: [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements Andy Lutomirski <luto@amacapital.net> - 2015-12-24 01:00 +0100
      Re: [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements Andy Lutomirski <luto@amacapital.net> - 2015-12-29 14:20 +0100

#1291437 — [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-14 19:40 +0100
Subject[PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements
Message-ID<qFGcp-1pc-3@gated-at.bofh.it>
This applies on top of the earlier vdso pvclock series I sent out.
Once that lands in -tip, this will apply to -tip.

This series cleans up the hack that is our vvar mapping.  We currently
initialize the vvar mapping as a special mapping vma backed by nothing
whatsoever and then we abuse remap_pfn_range to populate it.

This cheats the mm core, probably breaks under various evil madvise
workloads, and prevents handling faults in more interesting ways.

To clean it up, this series:

 - Adds a special mapping .fault operation
 - Adds a vm_insert_pfn_prot helper
 - Uses the new .fault infrastructure in x86's vdso and vvar mappings
 - Hardens the HPET mapping, mitigating an HW attack surface that bothers me

akpm, can you ack patck 1?

Changes from v1:
 - Lots of changelog clarification requested by akpm
 - Minor tweaks to style and comments in the first two patches

Andy Lutomirski (6):
  mm: Add a vm_special_mapping .fault method
  mm: Add vm_insert_pfn_prot
  x86/vdso: Track each mm's loaded vdso image as well as its base
  x86,vdso: Use .fault for the vdso text mapping
  x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping
  x86/vdso: Disallow vvar access to vclock IO for never-used vclocks

 arch/x86/entry/vdso/vdso2c.h            |   7 --
 arch/x86/entry/vdso/vma.c               | 124 ++++++++++++++++++++------------
 arch/x86/entry/vsyscall/vsyscall_gtod.c |   9 ++-
 arch/x86/include/asm/clocksource.h      |   9 +--
 arch/x86/include/asm/mmu.h              |   3 +-
 arch/x86/include/asm/vdso.h             |   3 -
 arch/x86/include/asm/vgtod.h            |   6 ++
 include/linux/mm.h                      |   2 +
 include/linux/mm_types.h                |  22 +++++-
 mm/memory.c                             |  25 ++++++-
 mm/mmap.c                               |  13 ++--
 11 files changed, 151 insertions(+), 72 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1291439 — [PATCH v2 2/6] mm: Add vm_insert_pfn_prot

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-14 19:40 +0100
Subject[PATCH v2 2/6] mm: Add vm_insert_pfn_prot
Message-ID<qFGcr-1pc-49@gated-at.bofh.it>
In reply to#1291437
The x86 vvar vma conntains pages with differing cacheability
flags.  x86 currently implements this by manually inserting all the ptes
using (io_)remap_pfn_range when the vma is set up.

x86 wants to move to using .fault with VM_FAULT_NOPAGE to set up the
mappings as needed.  The correct API to use to insert a pfn in
.fault is vm_insert_pfn, but vm_insert_pfn can't override the vma's
cache mode, and the HPET page in particular needs to be uncached
despite the fact that the rest of the VMA is cached.

Add vm_insert_pfn_prot to support varying cacheability within the
same non-COW VMA in a more sane manner.

x86 could alternatively use multiple VMAs, but that's messy, would
break CRIU, and would create unnecessary VMAs that would waste
memory.

Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---

Notes:
    Changes from v1:
     - Improve the changelog (akpm)

 include/linux/mm.h |  2 ++
 mm/memory.c        | 25 +++++++++++++++++++++++--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad7793788..87ef1d7730ba 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2080,6 +2080,8 @@ int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
 int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
 int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long pfn);
+int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
+			unsigned long pfn, pgprot_t pgprot);
 int vm_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long pfn);
 int vm_iomap_memory(struct vm_area_struct *vma, phys_addr_t start, unsigned long len);
diff --git a/mm/memory.c b/mm/memory.c
index c387430f06c3..a29f0b90fc56 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1564,8 +1564,29 @@ out:
 int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long pfn)
 {
+	return vm_insert_pfn_prot(vma, addr, pfn, vma->vm_page_prot);
+}
+EXPORT_SYMBOL(vm_insert_pfn);
+
+/**
+ * vm_insert_pfn_prot - insert single pfn into user vma with specified pgprot
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pfn: source kernel pfn
+ * @pgprot: pgprot flags for the inserted page
+ *
+ * This is exactly like vm_insert_pfn, except that it allows drivers to
+ * to override pgprot on a per-page basis.
+ *
+ * This only makes sense for IO mappings, and it makes no sense for
+ * cow mappings.  In general, using multiple vmas is preferable;
+ * vm_insert_pfn_prot should only be used if using multiple VMAs is
+ * impractical.
+ */
+int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
+			unsigned long pfn, pgprot_t pgprot)
+{
 	int ret;
-	pgprot_t pgprot = vma->vm_page_prot;
 	/*
 	 * Technically, architectures with pte_special can avoid all these
 	 * restrictions (same for remap_pfn_range).  However we would like
@@ -1587,7 +1608,7 @@ int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
 
 	return ret;
 }
-EXPORT_SYMBOL(vm_insert_pfn);
+EXPORT_SYMBOL(vm_insert_pfn_prot);
 
 int vm_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long pfn)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291440 — [PATCH v2 4/6] x86,vdso: Use .fault for the vdso text mapping

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-14 19:40 +0100
Subject[PATCH v2 4/6] x86,vdso: Use .fault for the vdso text mapping
Message-ID<qFGcr-1pc-47@gated-at.bofh.it>
In reply to#1291437
The old scheme for mapping the vdso text is rather complicated.  vdso2c
generates a struct vm_special_mapping and a blank .pages array of the
correct size for each vdso image.  Init code in vdso/vma.c populates
the .pages array for each vdso image, and the mapping code selects
the appropriate struct vm_special_mapping.

With .fault, we can use a less roundabout approach: vdso_fault
just returns the appropriate page for the selected vdso image.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/entry/vdso/vdso2c.h |  7 -------
 arch/x86/entry/vdso/vma.c    | 26 +++++++++++++++++++-------
 arch/x86/include/asm/vdso.h  |  3 ---
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
index 0224987556ce..abe961c7c71c 100644
--- a/arch/x86/entry/vdso/vdso2c.h
+++ b/arch/x86/entry/vdso/vdso2c.h
@@ -150,16 +150,9 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
 	}
 	fprintf(outfile, "\n};\n\n");
 
-	fprintf(outfile, "static struct page *pages[%lu];\n\n",
-		mapping_size / 4096);
-
 	fprintf(outfile, "const struct vdso_image %s = {\n", name);
 	fprintf(outfile, "\t.data = raw_data,\n");
 	fprintf(outfile, "\t.size = %lu,\n", mapping_size);
-	fprintf(outfile, "\t.text_mapping = {\n");
-	fprintf(outfile, "\t\t.name = \"[vdso]\",\n");
-	fprintf(outfile, "\t\t.pages = pages,\n");
-	fprintf(outfile, "\t},\n");
 	if (alt_sec) {
 		fprintf(outfile, "\t.alt = %lu,\n",
 			(unsigned long)GET_LE(&alt_sec->sh_offset));
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 80b021067bd6..eb50d7c1f161 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -27,13 +27,7 @@ unsigned int __read_mostly vdso64_enabled = 1;
 
 void __init init_vdso_image(const struct vdso_image *image)
 {
-	int i;
-	int npages = (image->size) / PAGE_SIZE;
-
 	BUG_ON(image->size % PAGE_SIZE != 0);
-	for (i = 0; i < npages; i++)
-		image->text_mapping.pages[i] =
-			virt_to_page(image->data + i*PAGE_SIZE);
 
 	apply_alternatives((struct alt_instr *)(image->data + image->alt),
 			   (struct alt_instr *)(image->data + image->alt +
@@ -90,6 +84,24 @@ static unsigned long vdso_addr(unsigned long start, unsigned len)
 #endif
 }
 
+static int vdso_fault(const struct vm_special_mapping *sm,
+		      struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+	const struct vdso_image *image = vma->vm_mm->context.vdso_image;
+
+	if (!image || (vmf->pgoff << PAGE_SHIFT) >= image->size)
+		return VM_FAULT_SIGBUS;
+
+	vmf->page = virt_to_page(image->data + (vmf->pgoff << PAGE_SHIFT));
+	get_page(vmf->page);
+	return 0;
+}
+
+static const struct vm_special_mapping text_mapping = {
+	.name = "[vdso]",
+	.fault = vdso_fault,
+};
+
 static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 {
 	struct mm_struct *mm = current->mm;
@@ -131,7 +143,7 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 				       image->size,
 				       VM_READ|VM_EXEC|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
-				       &image->text_mapping);
+				       &text_mapping);
 
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index deabaf9759b6..43dc55be524e 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -13,9 +13,6 @@ struct vdso_image {
 	void *data;
 	unsigned long size;   /* Always a multiple of PAGE_SIZE */
 
-	/* text_mapping.pages is big enough for data/size page pointers */
-	struct vm_special_mapping text_mapping;
-
 	unsigned long alt, alt_len;
 
 	long sym_vvar_start;  /* Negative offset to the vvar area */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291444 — [PATCH v2 3/6] x86/vdso: Track each mm's loaded vdso image as well as its base

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-14 19:40 +0100
Subject[PATCH v2 3/6] x86/vdso: Track each mm's loaded vdso image as well as its base
Message-ID<qFGcr-1pc-59@gated-at.bofh.it>
In reply to#1291437
As we start to do more intelligent things with the vdso at runtime
(as opposed to just at mm initialization time), we'll need to know
which vdso is in use.

In principle, we could guess based on the mm type, but that's
over-complicated and error-prone.  Instead, just track it in the mmu
context.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/entry/vdso/vma.c  | 1 +
 arch/x86/include/asm/mmu.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index b8f69e264ac4..80b021067bd6 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -121,6 +121,7 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 
 	text_start = addr - image->sym_vvar_start;
 	current->mm->context.vdso = (void __user *)text_start;
+	current->mm->context.vdso_image = image;
 
 	/*
 	 * MAYWRITE to allow gdb to COW and set breakpoints
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 55234d5e7160..1ea0baef1175 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -19,7 +19,8 @@ typedef struct {
 #endif
 
 	struct mutex lock;
-	void __user *vdso;
+	void __user *vdso;			/* vdso base address */
+	const struct vdso_image *vdso_image;	/* vdso image in use */
 
 	atomic_t perf_rdpmc_allowed;	/* nonzero if rdpmc is allowed */
 } mm_context_t;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297694

FromAndy Lutomirski <luto@amacapital.net>
Date2015-12-24 01:00 +0100
Message-ID<qJ1u1-7KM-9@gated-at.bofh.it>
In reply to#1291437
Hi Oleg and Kees-

I meant to cc you on this in the first place, but I failed.  If you
have a few minutes, want to take a peek at these and see if you can
poke any holes in them?  I'm reasonably confident that they're a
considerable improvement over the old state of affairs, but they might
still not be perfect.

Let me know if you want me to email out a fresh copy.  This series
applies to tip:x86/asm.

--Andy

On Mon, Dec 14, 2015 at 10:31 AM, Andy Lutomirski <luto@kernel.org> wrote:
> This applies on top of the earlier vdso pvclock series I sent out.
> Once that lands in -tip, this will apply to -tip.
>
> This series cleans up the hack that is our vvar mapping.  We currently
> initialize the vvar mapping as a special mapping vma backed by nothing
> whatsoever and then we abuse remap_pfn_range to populate it.
>
> This cheats the mm core, probably breaks under various evil madvise
> workloads, and prevents handling faults in more interesting ways.
>
> To clean it up, this series:
>
>  - Adds a special mapping .fault operation
>  - Adds a vm_insert_pfn_prot helper
>  - Uses the new .fault infrastructure in x86's vdso and vvar mappings
>  - Hardens the HPET mapping, mitigating an HW attack surface that bothers me
>
> akpm, can you ack patck 1?
>
> Changes from v1:
>  - Lots of changelog clarification requested by akpm
>  - Minor tweaks to style and comments in the first two patches
>
> Andy Lutomirski (6):
>   mm: Add a vm_special_mapping .fault method
>   mm: Add vm_insert_pfn_prot
>   x86/vdso: Track each mm's loaded vdso image as well as its base
>   x86,vdso: Use .fault for the vdso text mapping
>   x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping
>   x86/vdso: Disallow vvar access to vclock IO for never-used vclocks
>
>  arch/x86/entry/vdso/vdso2c.h            |   7 --
>  arch/x86/entry/vdso/vma.c               | 124 ++++++++++++++++++++------------
>  arch/x86/entry/vsyscall/vsyscall_gtod.c |   9 ++-
>  arch/x86/include/asm/clocksource.h      |   9 +--
>  arch/x86/include/asm/mmu.h              |   3 +-
>  arch/x86/include/asm/vdso.h             |   3 -
>  arch/x86/include/asm/vgtod.h            |   6 ++
>  include/linux/mm.h                      |   2 +
>  include/linux/mm_types.h                |  22 +++++-
>  mm/memory.c                             |  25 ++++++-
>  mm/mmap.c                               |  13 ++--
>  11 files changed, 151 insertions(+), 72 deletions(-)
>
> --
> 2.5.0
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298981

FromAndy Lutomirski <luto@amacapital.net>
Date2015-12-29 14:20 +0100
Message-ID<qL2lY-10g-5@gated-at.bofh.it>
In reply to#1297694
On Wed, Dec 23, 2015 at 3:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> Hi Oleg and Kees-
>
> I meant to cc you on this in the first place, but I failed.  If you
> have a few minutes, want to take a peek at these and see if you can
> poke any holes in them?  I'm reasonably confident that they're a
> considerable improvement over the old state of affairs, but they might
> still not be perfect.
>
> Let me know if you want me to email out a fresh copy.  This series
> applies to tip:x86/asm.

Hi -tip people:

please don't apply this series.  It has a race.  I'll send v3.

--Andy

>
> --Andy
>
> On Mon, Dec 14, 2015 at 10:31 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> This applies on top of the earlier vdso pvclock series I sent out.
>> Once that lands in -tip, this will apply to -tip.
>>
>> This series cleans up the hack that is our vvar mapping.  We currently
>> initialize the vvar mapping as a special mapping vma backed by nothing
>> whatsoever and then we abuse remap_pfn_range to populate it.
>>
>> This cheats the mm core, probably breaks under various evil madvise
>> workloads, and prevents handling faults in more interesting ways.
>>
>> To clean it up, this series:
>>
>>  - Adds a special mapping .fault operation
>>  - Adds a vm_insert_pfn_prot helper
>>  - Uses the new .fault infrastructure in x86's vdso and vvar mappings
>>  - Hardens the HPET mapping, mitigating an HW attack surface that bothers me
>>
>> akpm, can you ack patck 1?
>>
>> Changes from v1:
>>  - Lots of changelog clarification requested by akpm
>>  - Minor tweaks to style and comments in the first two patches
>>
>> Andy Lutomirski (6):
>>   mm: Add a vm_special_mapping .fault method
>>   mm: Add vm_insert_pfn_prot
>>   x86/vdso: Track each mm's loaded vdso image as well as its base
>>   x86,vdso: Use .fault for the vdso text mapping
>>   x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping
>>   x86/vdso: Disallow vvar access to vclock IO for never-used vclocks
>>
>>  arch/x86/entry/vdso/vdso2c.h            |   7 --
>>  arch/x86/entry/vdso/vma.c               | 124 ++++++++++++++++++++------------
>>  arch/x86/entry/vsyscall/vsyscall_gtod.c |   9 ++-
>>  arch/x86/include/asm/clocksource.h      |   9 +--
>>  arch/x86/include/asm/mmu.h              |   3 +-
>>  arch/x86/include/asm/vdso.h             |   3 -
>>  arch/x86/include/asm/vgtod.h            |   6 ++
>>  include/linux/mm.h                      |   2 +
>>  include/linux/mm_types.h                |  22 +++++-
>>  mm/memory.c                             |  25 ++++++-
>>  mm/mmap.c                               |  13 ++--
>>  11 files changed, 151 insertions(+), 72 deletions(-)
>>
>> --
>> 2.5.0
>>
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web