linux-kernel - Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

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: <3D823F02-89EF-48D9-913D-5E65391F6F9D@gmail.com>
Date:   Mon, 15 Jan 2018 12:09:41 -0800
From:   Nadav Amit <nadav.amit@...il.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>, w@....eu
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

Dave Hansen <dave.hansen@...ux.intel.com> wrote:

> On 01/14/2018 12:13 PM, Nadav Amit wrote:
>> Currently, when page-table isolation is on to prevent the Meltdown bug
>> (CVE-2017-5754), CR3 is always loaded on system-call and interrupt.
> 
> I think of PTI as being a defense against bad stuff that happens from
> the kernel being mapped into the user address space, with Meltdown being
> the most obvious "bad" thing.
> 
> What you're saying here is that since a 32-bit program can't address the
> kernel sitting at a >32-bit address, it does not need to unmap the
> kernel.  As Andy pointed out, there are a few holes with that assumption.

I think that Andy pointed out that my RFC may break existing programs, but
it should be relatively easy to fix. I don’t think there is any problem with
the assumption.

> IMNHO, any PTI-disabling mechanisms better be rock-solid, and easy to
> convince ourselves that they do the right thing.  For instance, the
> per-process PTI stuff is going to make the decision quite close to a
> capability check, which makes it fairly easy to get right.

Per-process PTI stuff is an easy solution, but it just pushes the decision
to the user, who is likely to disable PTI without thinking twice, especially
since he got no other option.

> If we start disabling PTI willy nilly at points _away_ from the
> capability checks (like for 32-bit binaries, say), then it gets really
> hard to decide if we are doing the right things.

Eventually it comes down to the question: what does the CPU do? I was
assuming that Intel can figure it out. If it is just about being “paranoid”,
I presume some paranoid knob should control this behavior.

> Also, what's the end goal here?  Run old 32-bit binaries better?  You
> want to weaken the security of the whole implementation to do that?
> Sounds like a bad tradeoff to me.

As Willy noted in this thread, I think that some users may be interested in
running 32-bit Apache/Nginx/Redis to get the performance back without
sacrificing security.