linux-kernel - Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

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:   Tue, 22 Nov 2016 09:30:43 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Brian Gerst <brgerst@...il.com>,
        Andy Lutomirski <luto@...nel.org>, tedheadster@...il.com,
        "H. Peter Anvin" <hpa@...or.com>,
        George Spelvin <linux@...izon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>
Subject: Re: What exactly do 32-bit x86 exceptions push on the stack in the
 CS slot?

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > So I have applied your fix that addresses the worst fallout directly:
> >
> >   fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in early_fixup_exception()
> >
> > ... but otherwise we might be better off zeroing out the high bits of segment
> > registers stored on the stack, in all entry code pathways
> 
> Ugh.
> 
> I'd much rather we go back to just making the "cs" entry explicitly
> 16-bit, and have a separate padding entry, the way we used to long
> long ago.
> 
> Or just rename it to something that you're not supposed to access
> directly, and a helper accessor function that masks off the high bits.
> 
> The entry code-paths are *much* more critical than any of the few user
> codepaths.

Absolutely, no arguments about that!

> [...] Let's not add complexity to entry. Make the structure actually reflect 
> reality instead.

So I have no problems at all with your suggestion either.

I am still trying to semi-defend my suggestion as well, because if we do what I 
suggested:

> > [...] so that the function call is patched out on modern CPUs.

then it's essentially an opt-in quirk for really old CPUs and won't impact new 
CPUs, other than a single NOP for the patched out bits - and not even that on 
kernel builds with M686 or later or so ...

I.e. the quirk essentially implements what new CPUs do (in C), and then all 
remaining code can just assume that all data is properly initialized/zeroed like 
on new CPUs and the effects of the quirk does not spread to data structures and 
code that handles and copies around those data structures - unless I'm missing 
something.

Thanks,

	Ingo