linux-kernel - RE: [patch 11/16] x86/ldt: Force access bit for CS/SS

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] [day] [month] [year] [list]

Date:   Tue, 19 Dec 2017 12:10:34 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...capital.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Andy Lutomirsky <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Borislav Petkov <bpetkov@...e.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Kees Cook" <keescook@...gle.com>, Hugh Dickins <hughd@...gle.com>,
        Brian Gerst <brgerst@...il.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        "Juergen Gross" <jgross@...e.com>,
        Eduardo Valentin <eduval@...zon.com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        Will Deacon <will.deacon@....com>,
        linux-mm <linux-mm@...ck.org>
Subject: RE: [patch 11/16] x86/ldt: Force access bit for CS/SS

From: Andy Lutomirski
> Sent: 12 December 2017 19:27
...
> > Why is the iret exception unrecoverable anyway? Does anybody even know?
> >
> 
> Weird microcode shit aside, a fault on IRET will return to kernel code with kernel GS, and then the
> next time we enter the kernel we're backwards.  We could fix idtentry to get this right, but the code
> is already tangled enough.
...

Notwithstanding a readonly LDT, the iret (and pop %ds, pop %es that probably
precede it) are all likely to fault in kernel if the segment registers are invalid.
(Setting %fs and %gs for 32 bit processes is left to the reader.)

Unlike every other fault in the kernel code segment, gsbase will contain
the user value, not the kernel one.

The kernel code must detect this somehow and correct everything before (probably)
generating a SIGSEGV and returning to the user's signal handler with the
invalid segment registers in the signal context.

Assuming this won't happen (because the segment registers are always valid)
is likely to be a recipe for disaster (or an escalation).

I guess the problem with a readonly LDT is that you don't want to fault
setting the 'accesses' bit.

	David