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
prev parent 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®