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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ