linux-kernel - Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

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, 12 Dec 2017 20:21:22 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     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>,
        David Laight <David.Laight@...lab.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 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Linus Torvalds wrote:

> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > From: Thomas Gleixner <tglx@...utronix.de>
> >
> > When the LDT is mapped RO, the CPU will write fault the first time it uses
> > a segment descriptor in order to set the ACCESS bit (for some reason it
> > doesn't always observe that it already preset). Catch the fault and set the
> > ACCESS bit in the handler.
> 
> This really scares me.
> 
> We use segments in some critical code in the kernel, like the whole
> percpu data etc. Stuff that definitely shouldn't fault.
> 
> Yes, those segments should damn well be already marked accessed when
> the segment is loaded, but apparently that isn't reliable.

That has nothing to do with the user installed LDT. The kernel does not use
and rely on LDT at all.

The only critical interaction is the return to user path (user CS/SS) and
we made sure with the LAR touching that these are precached in the CPU
before we go into fragile exit code. Luto has some concerns
vs. load_gs[_index] and we'll certainly look into that some more.

Thanks,

	tglx