mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>, Brian Gerst <brgerst@gmail.com>,
	David Laight <David.Laight@aculab.com>,
	Kees Cook <keescook@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH PTI v2 0/6] Clean up pgd handling and fix VSYSCALL and LDT
Date: Tue, 12 Dec 2017 19:01:26 +0300	[thread overview]
Message-ID: <20171212160126.kqsymv66wvee4oy7@node.shutemov.name> (raw)
In-Reply-To: <CALCETrV8gJW39GeiK=ejuB1yDyo1DhcKFYR5qzUNQkAYTQa=8w@mail.gmail.com>

On Sun, Dec 10, 2017 at 10:54:38PM -0800, Andy Lutomirski wrote:
> On Sun, Dec 10, 2017 at 10:47 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > I'm getting reasonably happy with this.  It still needs more testing,
> > but I want to get it out there.
> >
> > The main things that need testing are the 5-level case for the both
> > vsyscalls and the LDT.  I'm getting a double-fault in ldt_gdt_64,
> > but I haven't checked whether it's a bug in this series, and it
> > kind of looks like it isn't.  I'll figure it out in the morning.
> > The docs also want updating for the 5 level case.
> >
> 
> The actual failure looks a lot like the ESPFIX stacks aren't mapped in
> the usermode tables, which reinforces my old belief that this bit of
> code is bogus:
> 
>     /*
>      * Just copy the top-level PGD that is mapping the espfix area to
>      * ensure it is mapped into the user page tables.
>      *
>      * For 5-level paging, the espfix pgd was populated when
>      * pti_init() pre-populated all the pgd entries.  The above
>      * p4d_alloc() would never do anything and the p4d_populate() would
>      * be done to a p4d already mapped in the userspace pgd.
>      */
> #ifdef CONFIG_PAGE_TABLE_ISOLATION
>     if (CONFIG_PGTABLE_LEVELS <= 4) {
>         set_pgd(kernel_to_user_pgdp(pgd),
>             __pgd(_KERNPG_TABLE | (p4d_pfn(*p4d) << PAGE_SHIFT)));
>     }
> #endif
> 
> Of course, the comment is even more wrong with this series applied,
> but I think it's been wrong all along.
> 
> I'll fix it in the morning if no one beats me to it.
> 
> (Hint: this can be tested in QEMU with -machine accel=tcg -cpu qemu64,+la57)

I thought something like patch below would help (for both paging modes). It
indeed made sigreturn_64 run a bit longer in 5-level paging mode, but it still
double faults in the end.

Maybe it's another bug. I don't know. I don't have time right now to look into.

BTW, sigreturn_64 reports FAILS in 4-level paging mode.

t a/arch/x86/kernel/espfix_64.c b/arch/x86/kernel/espfix_64.c
index 1c44e72ed1bc..0725c04b2d3f 100644
--- a/arch/x86/kernel/espfix_64.c
+++ b/arch/x86/kernel/espfix_64.c
@@ -129,20 +129,11 @@ void __init init_espfix_bsp(void)
 	p4d = p4d_alloc(&init_mm, pgd, ESPFIX_BASE_ADDR);
 	p4d_populate(&init_mm, p4d, espfix_pud_page);
 
-	/*
-	 * Just copy the top-level PGD that is mapping the espfix area to
-	 * ensure it is mapped into the user page tables.
-	 *
-	 * For 5-level paging, the espfix pgd was populated when
-	 * pti_init() pre-populated all the pgd entries.  The above
-	 * p4d_alloc() would never do anything and the p4d_populate() would
-	 * be done to a p4d already mapped in the userspace pgd.
-	 */
 #ifdef CONFIG_PAGE_TABLE_ISOLATION
-	if (CONFIG_PGTABLE_LEVELS <= 4) {
-		set_pgd(kernel_to_user_pgdp(pgd),
-			__pgd(_KERNPG_TABLE | (p4d_pfn(*p4d) << PAGE_SHIFT)));
-	}
+	/* Install the espfix pud into user space page tables too */
+	pgd = kernel_to_user_pgdp(pgd);
+	p4d = p4d_alloc(&init_mm, pgd, ESPFIX_BASE_ADDR);
+	p4d_populate(&init_mm, p4d, espfix_pud_page);
 #endif
 
 	/* Randomize the locations */
-- 
 Kirill A. Shutemov

      reply	other threads:[~2017-12-12 16:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11  6:47 Andy Lutomirski
2017-12-11  6:47 ` [PATCH PTI v2 1/6] x86/pti: Vastly simplify pgd synchronization Andy Lutomirski
2017-12-11  6:47 ` [PATCH PTI v2 2/6] Revert "x86/mm/pti: Disable native VSYSCALL" Andy Lutomirski
2017-12-11  6:47 ` [PATCH PTI v2 3/6] x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy Andy Lutomirski
2017-12-11 13:39   ` Ingo Molnar
2017-12-11 16:01     ` Andy Lutomirski
2017-12-11 16:24       ` Ingo Molnar
2017-12-11  6:47 ` [PATCH PTI v2 4/6] x86/vsyscall/64: Warn and fail vsyscall emulation in NATIVE mode Andy Lutomirski
2017-12-11  6:47 ` [PATCH PTI v2 5/6] x86/pti: Map the vsyscall page if needed Andy Lutomirski
2017-12-11  6:47 ` [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on Andy Lutomirski
2017-12-11 17:49   ` Dave Hansen
2017-12-11 18:40     ` Andy Lutomirski
2017-12-11 19:32       ` Dave Hansen
2017-12-11 19:39         ` Andy Lutomirski
2017-12-11 19:47           ` Dave Hansen
2017-12-11 20:06             ` Andy Lutomirski
2017-12-11  6:54 ` [PATCH PTI v2 0/6] Clean up pgd handling and fix VSYSCALL and LDT Andy Lutomirski
2017-12-12 16:01   ` Kirill A. Shutemov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171212160126.kqsymv66wvee4oy7@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=David.Laight@aculab.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®