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]

Message-ID: <CA+55aFwgGDa_JfZZPoaYtw5yE1oYnn1+0t51D=WU8a7__1Lauw@mail.gmail.com>
Date:   Tue, 12 Dec 2017 11:01:18 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
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, 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.

So it potentially takes faults in random and very critical places.
It's probably dependent on microarchitecture on exactly when the
cached segment copy has the accessed bit set or not.

Also, I worry about crazy errata with TSS etc - this whole RO LDT
thing also introduces lots of possible new fault points in microcode
that nobody sane has ever done before, no?

> +       desc = (struct desc_struct *) ldt->entries;
> +       entry = (address - start) / LDT_ENTRY_SIZE;
> +       desc[entry].type |= 0x01;

This is also pretty disgusting.

Why isn't it just something like

      desc = (void *)(address & ~(LDT_ENTRY_SIZE-1));
      desc->type != 0x01;

since the ldt should all be aligned anyway.

                Linus