[PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Andy Lutomirski]

Neil Berrington reported a double-fault on a VM with 768GB of RAM that
uses large amounts of vmalloc space with PTI enabled.

The cause is that load_new_mm_cr3() was never fixed to take the
5-level pgd folding code into account, so, on a 4-level kernel, the
pgd synchronization logic compiles away to exactly nothing.

Interestingly, the problem doesn't trigger with nopti.  I assume this
is because the kernel is mapped with global pages if we boot with
nopti.  The sequence of operations when we create a new task is that
we first load its mm while still running on the old stack (which
crashes if the old stack is unmapped in the new mm unless the TLB
saves us), then we call prepare_switch_to(), and then we switch to the
new stack.  prepare_switch_to() pokes the new stack directly, which
will populate the mapping through vmalloc_fault().  I assume that
we're getting lucky on non-PTI systems -- the old stack's TLB entry
stays alive long enough to make it all the way through
prepare_switch_to() and switch_to() so that we make it to a valid
stack.

Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support")
Cc: stable@vger.kernel.org
Reported-and-tested-by: Neil Berrington <neil.berrington@datacore.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index a1561957dccb..5bfe61a5e8e3 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next,
 	local_irq_restore(flags);
 }
 
+static void sync_current_stack_to_mm(struct mm_struct *mm)
+{
+	unsigned long sp = current_stack_pointer;
+	pgd_t *pgd = pgd_offset(mm, sp);
+
+	if (CONFIG_PGTABLE_LEVELS > 4) {
+		if (unlikely(pgd_none(*pgd))) {
+			pgd_t *pgd_ref = pgd_offset_k(sp);
+
+			set_pgd(pgd, *pgd_ref);
+		}
+	} else {
+		/*
+		 * "pgd" is faked.  The top level entries are "p4d"s, so sync
+		 * the p4d.  This compiles to approximately the same code as
+		 * the 5-level case.
+		 */
+		p4d_t *p4d = p4d_offset(pgd, sp);
+
+		if (unlikely(p4d_none(*p4d))) {
+			pgd_t *pgd_ref = pgd_offset_k(sp);
+			p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
+
+			set_p4d(p4d, *p4d_ref);
+		}
+	}
+}
+
 void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
 			struct task_struct *tsk)
 {
@@ -226,11 +254,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
 			 * mapped in the new pgd, we'll double-fault.  Forcibly
 			 * map it.
 			 */
-			unsigned int index = pgd_index(current_stack_pointer);
-			pgd_t *pgd = next->pgd + index;
-
-			if (unlikely(pgd_none(*pgd)))
-				set_pgd(pgd, init_mm.pgd[index]);
+			sync_current_stack_to_mm(next);
 		}
 
 		/* Stop remote flushes for the previous mm */
-- 
2.14.3

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Dave Hansen]

On 01/25/2018 01:12 PM, Andy Lutomirski wrote:
> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> uses large amounts of vmalloc space with PTI enabled.
> 
> The cause is that load_new_mm_cr3() was never fixed to take the
> 5-level pgd folding code into account, so, on a 4-level kernel, the
> pgd synchronization logic compiles away to exactly nothing.

You don't mention it, but we can normally handle vmalloc() faults in the
kernel that are due to unsynchronized page tables.  The thing that kills
us here is that we have an unmapped stack and we try to use that stack
when entering the page fault handler, which double faults.  The double
fault handler gets a new stack and saves us enough to get an oops out.

Right?

> +static void sync_current_stack_to_mm(struct mm_struct *mm)
> +{
> +	unsigned long sp = current_stack_pointer;
> +	pgd_t *pgd = pgd_offset(mm, sp);
> +
> +	if (CONFIG_PGTABLE_LEVELS > 4) {
> +		if (unlikely(pgd_none(*pgd))) {
> +			pgd_t *pgd_ref = pgd_offset_k(sp);
> +
> +			set_pgd(pgd, *pgd_ref);
> +		}
> +	} else {
> +		/*
> +		 * "pgd" is faked.  The top level entries are "p4d"s, so sync
> +		 * the p4d.  This compiles to approximately the same code as
> +		 * the 5-level case.
> +		 */
> +		p4d_t *p4d = p4d_offset(pgd, sp);
> +
> +		if (unlikely(p4d_none(*p4d))) {
> +			pgd_t *pgd_ref = pgd_offset_k(sp);
> +			p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
> +
> +			set_p4d(p4d, *p4d_ref);
> +		}
> +	}
> +}

We keep having to add these.  It seems like a real deficiency in the
mechanism that we're using for pgd folding.  Can't we get a warning or
something when we try to do a set_pgd() that's (silently) not doing
anything?  This exact same pattern bit me more than once with the
KPTI/KAISER patches.

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Andy Lutomirski]

On Thu, Jan 25, 2018 at 1:49 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> On 01/25/2018 01:12 PM, Andy Lutomirski wrote:
>> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
>> uses large amounts of vmalloc space with PTI enabled.
>>
>> The cause is that load_new_mm_cr3() was never fixed to take the
>> 5-level pgd folding code into account, so, on a 4-level kernel, the
>> pgd synchronization logic compiles away to exactly nothing.
>
> You don't mention it, but we can normally handle vmalloc() faults in the
> kernel that are due to unsynchronized page tables.  The thing that kills
> us here is that we have an unmapped stack and we try to use that stack
> when entering the page fault handler, which double faults.  The double
> fault handler gets a new stack and saves us enough to get an oops out.
>
> Right?

Exactly.

There are two special code paths that can't use vmalloc_fault(): this
one and switch_to().  The latter avoids explicit page table fiddling
and just touches the new stack before loading it into rsp.

>
>> +static void sync_current_stack_to_mm(struct mm_struct *mm)
>> +{
>> +     unsigned long sp = current_stack_pointer;
>> +     pgd_t *pgd = pgd_offset(mm, sp);
>> +
>> +     if (CONFIG_PGTABLE_LEVELS > 4) {
>> +             if (unlikely(pgd_none(*pgd))) {
>> +                     pgd_t *pgd_ref = pgd_offset_k(sp);
>> +
>> +                     set_pgd(pgd, *pgd_ref);
>> +             }
>> +     } else {
>> +             /*
>> +              * "pgd" is faked.  The top level entries are "p4d"s, so sync
>> +              * the p4d.  This compiles to approximately the same code as
>> +              * the 5-level case.
>> +              */
>> +             p4d_t *p4d = p4d_offset(pgd, sp);
>> +
>> +             if (unlikely(p4d_none(*p4d))) {
>> +                     pgd_t *pgd_ref = pgd_offset_k(sp);
>> +                     p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
>> +
>> +                     set_p4d(p4d, *p4d_ref);
>> +             }
>> +     }
>> +}
>
> We keep having to add these.  It seems like a real deficiency in the
> mechanism that we're using for pgd folding.  Can't we get a warning or
> something when we try to do a set_pgd() that's (silently) not doing
> anything?  This exact same pattern bit me more than once with the
> KPTI/KAISER patches.

Hmm, maybe.

What I'd really like to see is an entirely different API.  Maybe:

typedef struct {
  opaque, but probably includes:
  int depth;  /* 0 is root */
  void *table;
} ptbl_ptr;

ptbl_ptr root_table = mm_root_ptbl(mm);

set_ptbl_entry(root_table, pa, prot);

/* walk tables */
ptbl_ptr pt = ...;
ptentry_ptr entry;
while (ptbl_has_children(pt)) {
  pt = pt_next(pt, addr);
}
entry = pt_entry_at(pt, addr);
/* do something with entry */

etc.

Now someone can add a sixth level without changing every code path in
the kernel that touches page tables.

--Andy

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Ingo Molnar]

* Andy Lutomirski <luto@kernel.org> wrote:

> What I'd really like to see is an entirely different API.  Maybe:
> 
> typedef struct {
>   opaque, but probably includes:
>   int depth;  /* 0 is root */
>   void *table;
> } ptbl_ptr;
> 
> ptbl_ptr root_table = mm_root_ptbl(mm);
> 
> set_ptbl_entry(root_table, pa, prot);
> 
> /* walk tables */
> ptbl_ptr pt = ...;
> ptentry_ptr entry;
> while (ptbl_has_children(pt)) {
>   pt = pt_next(pt, addr);
> }
> entry = pt_entry_at(pt, addr);
> /* do something with entry */
> 
> etc.
> 
> Now someone can add a sixth level without changing every code path in
> the kernel that touches page tables.

Iteration based page table lookups would be neat.

A sixth level is unavoidable on x86-64 I think - we'll get there in a decade or 
so? The sixth level will also use up the last ~8 bits of virtual memory available 
on 64-bit.

Thanks,

	Ingo

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Kirill A. Shutemov]

On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> uses large amounts of vmalloc space with PTI enabled.
> 
> The cause is that load_new_mm_cr3() was never fixed to take the
> 5-level pgd folding code into account, so, on a 4-level kernel, the
> pgd synchronization logic compiles away to exactly nothing.

Ouch. Sorry for this.

> 
> Interestingly, the problem doesn't trigger with nopti.  I assume this
> is because the kernel is mapped with global pages if we boot with
> nopti.  The sequence of operations when we create a new task is that
> we first load its mm while still running on the old stack (which
> crashes if the old stack is unmapped in the new mm unless the TLB
> saves us), then we call prepare_switch_to(), and then we switch to the
> new stack.  prepare_switch_to() pokes the new stack directly, which
> will populate the mapping through vmalloc_fault().  I assume that
> we're getting lucky on non-PTI systems -- the old stack's TLB entry
> stays alive long enough to make it all the way through
> prepare_switch_to() and switch_to() so that we make it to a valid
> stack.
> 
> Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support")
> Cc: stable@vger.kernel.org
> Reported-and-tested-by: Neil Berrington <neil.berrington@datacore.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++-----
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index a1561957dccb..5bfe61a5e8e3 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>  	local_irq_restore(flags);
>  }
>  
> +static void sync_current_stack_to_mm(struct mm_struct *mm)
> +{
> +	unsigned long sp = current_stack_pointer;
> +	pgd_t *pgd = pgd_offset(mm, sp);
> +
> +	if (CONFIG_PGTABLE_LEVELS > 4) {

Can we have

	if (PTRS_PER_P4D > 1)

here instead? This way I wouldn't need to touch the code again for
boot-time switching support.

-- 
 Kirill A. Shutemov

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Kirill A. Shutemov]

On Thu, Jan 25, 2018 at 02:00:22PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 25, 2018 at 1:49 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> > On 01/25/2018 01:12 PM, Andy Lutomirski wrote:
> >> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> >> uses large amounts of vmalloc space with PTI enabled.
> >>
> >> The cause is that load_new_mm_cr3() was never fixed to take the
> >> 5-level pgd folding code into account, so, on a 4-level kernel, the
> >> pgd synchronization logic compiles away to exactly nothing.
> >
> > You don't mention it, but we can normally handle vmalloc() faults in the
> > kernel that are due to unsynchronized page tables.  The thing that kills
> > us here is that we have an unmapped stack and we try to use that stack
> > when entering the page fault handler, which double faults.  The double
> > fault handler gets a new stack and saves us enough to get an oops out.
> >
> > Right?
> 
> Exactly.
> 
> There are two special code paths that can't use vmalloc_fault(): this
> one and switch_to().  The latter avoids explicit page table fiddling
> and just touches the new stack before loading it into rsp.
> 
> >
> >> +static void sync_current_stack_to_mm(struct mm_struct *mm)
> >> +{
> >> +     unsigned long sp = current_stack_pointer;
> >> +     pgd_t *pgd = pgd_offset(mm, sp);
> >> +
> >> +     if (CONFIG_PGTABLE_LEVELS > 4) {
> >> +             if (unlikely(pgd_none(*pgd))) {
> >> +                     pgd_t *pgd_ref = pgd_offset_k(sp);
> >> +
> >> +                     set_pgd(pgd, *pgd_ref);
> >> +             }
> >> +     } else {
> >> +             /*
> >> +              * "pgd" is faked.  The top level entries are "p4d"s, so sync
> >> +              * the p4d.  This compiles to approximately the same code as
> >> +              * the 5-level case.
> >> +              */
> >> +             p4d_t *p4d = p4d_offset(pgd, sp);
> >> +
> >> +             if (unlikely(p4d_none(*p4d))) {
> >> +                     pgd_t *pgd_ref = pgd_offset_k(sp);
> >> +                     p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
> >> +
> >> +                     set_p4d(p4d, *p4d_ref);
> >> +             }
> >> +     }
> >> +}
> >
> > We keep having to add these.  It seems like a real deficiency in the
> > mechanism that we're using for pgd folding.  Can't we get a warning or
> > something when we try to do a set_pgd() that's (silently) not doing
> > anything?  This exact same pattern bit me more than once with the
> > KPTI/KAISER patches.
> 
> Hmm, maybe.
> 
> What I'd really like to see is an entirely different API.  Maybe:
> 
> typedef struct {
>   opaque, but probably includes:
>   int depth;  /* 0 is root */
>   void *table;
> } ptbl_ptr;
> 
> ptbl_ptr root_table = mm_root_ptbl(mm);
> 
> set_ptbl_entry(root_table, pa, prot);
> 
> /* walk tables */
> ptbl_ptr pt = ...;
> ptentry_ptr entry;
> while (ptbl_has_children(pt)) {
>   pt = pt_next(pt, addr);
> }
> entry = pt_entry_at(pt, addr);
> /* do something with entry */
> 
> etc.

I thought about very similar design, but never got time to try it really.
It's not one-week-end type of project :/

-- 
 Kirill A. Shutemov

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Andy Lutomirski]

On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
>> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
>> uses large amounts of vmalloc space with PTI enabled.
>>
>> The cause is that load_new_mm_cr3() was never fixed to take the
>> 5-level pgd folding code into account, so, on a 4-level kernel, the
>> pgd synchronization logic compiles away to exactly nothing.
>
> Ouch. Sorry for this.
>
>>
>> Interestingly, the problem doesn't trigger with nopti.  I assume this
>> is because the kernel is mapped with global pages if we boot with
>> nopti.  The sequence of operations when we create a new task is that
>> we first load its mm while still running on the old stack (which
>> crashes if the old stack is unmapped in the new mm unless the TLB
>> saves us), then we call prepare_switch_to(), and then we switch to the
>> new stack.  prepare_switch_to() pokes the new stack directly, which
>> will populate the mapping through vmalloc_fault().  I assume that
>> we're getting lucky on non-PTI systems -- the old stack's TLB entry
>> stays alive long enough to make it all the way through
>> prepare_switch_to() and switch_to() so that we make it to a valid
>> stack.
>>
>> Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support")
>> Cc: stable@vger.kernel.org
>> Reported-and-tested-by: Neil Berrington <neil.berrington@datacore.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>>  arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++-----
>>  1 file changed, 29 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index a1561957dccb..5bfe61a5e8e3 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>>       local_irq_restore(flags);
>>  }
>>
>> +static void sync_current_stack_to_mm(struct mm_struct *mm)
>> +{
>> +     unsigned long sp = current_stack_pointer;
>> +     pgd_t *pgd = pgd_offset(mm, sp);
>> +
>> +     if (CONFIG_PGTABLE_LEVELS > 4) {
>
> Can we have
>
>         if (PTRS_PER_P4D > 1)
>
> here instead? This way I wouldn't need to touch the code again for
> boot-time switching support.

Want to send a patch?

(Also, I haven't noticed a patch to fix up the SYSRET checking for
boot-time switching.  Have I just missed it?)

--Andy

Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems

[Kirill A. Shutemov]

On Fri, Jan 26, 2018 at 11:02:08AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
> >> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> >> uses large amounts of vmalloc space with PTI enabled.
> >>
> >> The cause is that load_new_mm_cr3() was never fixed to take the
> >> 5-level pgd folding code into account, so, on a 4-level kernel, the
> >> pgd synchronization logic compiles away to exactly nothing.
> >
> > Ouch. Sorry for this.
> >
> >>
> >> Interestingly, the problem doesn't trigger with nopti.  I assume this
> >> is because the kernel is mapped with global pages if we boot with
> >> nopti.  The sequence of operations when we create a new task is that
> >> we first load its mm while still running on the old stack (which
> >> crashes if the old stack is unmapped in the new mm unless the TLB
> >> saves us), then we call prepare_switch_to(), and then we switch to the
> >> new stack.  prepare_switch_to() pokes the new stack directly, which
> >> will populate the mapping through vmalloc_fault().  I assume that
> >> we're getting lucky on non-PTI systems -- the old stack's TLB entry
> >> stays alive long enough to make it all the way through
> >> prepare_switch_to() and switch_to() so that we make it to a valid
> >> stack.
> >>
> >> Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support")
> >> Cc: stable@vger.kernel.org
> >> Reported-and-tested-by: Neil Berrington <neil.berrington@datacore.com>
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >> ---
> >>  arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++-----
> >>  1 file changed, 29 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> >> index a1561957dccb..5bfe61a5e8e3 100644
> >> --- a/arch/x86/mm/tlb.c
> >> +++ b/arch/x86/mm/tlb.c
> >> @@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next,
> >>       local_irq_restore(flags);
> >>  }
> >>
> >> +static void sync_current_stack_to_mm(struct mm_struct *mm)
> >> +{
> >> +     unsigned long sp = current_stack_pointer;
> >> +     pgd_t *pgd = pgd_offset(mm, sp);
> >> +
> >> +     if (CONFIG_PGTABLE_LEVELS > 4) {
> >
> > Can we have
> >
> >         if (PTRS_PER_P4D > 1)
> >
> > here instead? This way I wouldn't need to touch the code again for
> > boot-time switching support.
> 
> Want to send a patch?

I'll send it with the rest of boot-time switching stuff.

> (Also, I haven't noticed a patch to fix up the SYSRET checking for
> boot-time switching.  Have I just missed it?)

It's not upstream yet.

There are two patches: initial boot-time switching support and optimization on
top of it.

https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/wip&id=c35fc0af7a4fe9b5369134d7485d95427a0a039b
https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/wip&id=fae0e6c3eb253e63532f4ecfa6705aac2c5d710c

-- 
 Kirill A. Shutemov