linux-kernel - Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Jan 2018 10:55:23 +0100
From:   Joerg Roedel <joro@...tes.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Brian Gerst <brgerst@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Eduardo Valentin <eduval@...zon.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        Hugh Dickins <hughd@...gle.com>,
        Kees Cook <keescook@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Waiman Long <llong@...hat.com>, Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

Hey Andy,

On Wed, Jan 17, 2018 at 10:10:23AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel <joro@...tes.org> wrote:

> > Just read up on vm86 mode control transfers and the stack layout then.
> > Looks like I need to check for eflags.vm=1 and copy four more registers
> > from/to the entry stack. Thanks for pointing that out.
> 
> You could just copy those slots unconditionally.  After all, you're
> slowing down entries by an epic amount due to writing CR3 on with PCID
> off, so four words copied should be entirely lost in the noise.  OTOH,
> checking for VM86 mode is just a single bt against EFLAGS.
> 
> With the modern (rewritten a year or two ago by Brian Gerst) vm86
> code, all the slots (those actually in pt_regs) are in the same
> location regardless of whether we're in VM86 mode or not, but we're
> still fiddling with the bottom of the stack.  Since you're controlling
> the switch to the kernel thread stack, you can easily just write the
> frame to the correct location, so you should not need to context
> switch sp1 -- you can do it sanely and leave sp1 as the actual bottom
> of the kernel stack no matter what.  In fact, you could probably avoid
> context switching sp0, either, which would be a nice cleanup.

I am not sure what you mean by "not context switching sp0/sp1" ...

> So I recommend the following.  Keep sp0 as the bottom of the sysenter
> stack no matter what.  Then do:
> 
> bt $X86_EFLAGS_VM_BIT
> jc .Lfrom_vm_\@
> 
> push 5 regs to real stack, starting at four-word offset (so they're in
> the right place)
> update %esp
> ...
> .Lupdate_esp_\@
> 
> .Lfrom_vm_\@:
> push 9 regs to real stack, starting at the bottom
> jmp .Lupdate_esp_\@
> 
> Does that seem reasonable?  It's arguably much nicer than what we have
> now.

But that looks like a good idea. Having a consistent stack with and
without vm86 is certainly a nice cleanup.


Regards,

	Joerg