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:   Sun, 21 Jan 2018 18:11:07 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nadav Amit <nadav.amit@...il.com>
Cc:     Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Brian Gerst <brgerst@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Eduardo Valentin <eduval@...zon.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        Hugh Dickins <hughd@...gle.com>,
        Kees Cook <keescook@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Waiman Long <llong@...hat.com>, Joerg Roedel <jroedel@...e.de>
Subject: Re: [RFC PATCH 00/16] PTI support for x86-32

On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit <nadav.amit@...il.com> wrote:
> I wanted to see whether segments protection can be a replacement for PTI
> (yes, excluding SMEP emulation), or whether speculative execution “ignores”
> limit checks, similarly to the way paging protection is skipped.
>
> It does seem that segmentation provides sufficient protection from Meltdown.
> The “reliability” test of Gratz PoC fails if the segment limit is set to
> prevent access to the kernel memory. [ It passes if the limit is not set,
> even if the DS is reloaded. ] My test is enclosed below.

Interesting. It might not be entirely reliable for all
microarchitectures, though.

> So my question: wouldn’t it be much more efficient to use segmentation
> protection for x86-32, and allow users to choose whether they want SMEP-like
> protection if needed (and then enable PTI)?

That's what we did long long ago, with user space segments actually
using the limit (in fact, if you go back far enough, the kernel even
used the base).

You'd have to make sure that the LDT loading etc do not allow CPL3
segments with base+limit past TASK_SIZE, so that people can't generate
their own.  And the TLS segments also need to be limited (and
remember, the limit has to be TASK_SIZE-base, not just TASK_SIZE).

And we should check with Intel that segment limit checking really is
guaranteed to be done before any access.

Too bad x86-64 got rid of the segments ;)

               Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ