linux-kernel - Re: [PATCH 30/43] x86/mm/kaiser: Map espfix structures

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171127091424.zvfg7fsr7v2kfxnl@hirez.programming.kicks-ass.net>
Date:   Mon, 27 Nov 2017 10:14:24 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 30/43] x86/mm/kaiser: Map espfix structures

On Fri, Nov 24, 2017 at 08:17:06AM -0800, Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 5:47 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote:
> >> From: Dave Hansen <dave.hansen@...ux.intel.com>
> >>
> >> There is some rather arcane code to help when an IRET returns
> >> to 16-bit segments.  It is referred to as the "espfix" code.
> >> This consists of a few per-cpu variables:
> >>
> >>       espfix_stack: tells us where the stack is allocated
> >>                     (the bottom)
> >>       espfix_waddr: tells us to where %rsp may be pointed
> >>                     (the top)
> >>
> >> These are in addition to the stack itself.  All three things must
> >> be mapped for the espfix code to function.
> >>
> >> Note: the espfix code runs with a kernel GSBASE, but user
> >> (shadow) page tables.  A switch to the kernel page tables could
> >> be performed instead of mapping these structures, but mapping
> >> them is simpler and less likely to break the assembly.  To switch
> >> over to the kernel copy, additional temporary storage would be
> >> required which is in short supply in this context.
> >
> > With Andy's patches that should actually be doable, no?
> 
> I don't think it has much to do with my patches.  We can freely spill
> to the stack in the espfix64 code, though.

Ah, I was thinking of how you made scratch space easier for the SYSENTER
stuff.

But if we can freely spill here, should we not do the kernel switch
instead of doing this user mapping? The way I understand things, the
less of these magic mappings we have the better.