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]

Date:   Mon, 15 Jan 2018 11:49:19 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Nadav Amit <namit@...are.com>, linux-kernel@...r.kernel.org
Cc:     luto@...nel.org, tglx@...utronix.de, mingo@...hat.com,
        hpa@...or.com, x86@...nel.org, nadav.amit@...il.com, w@....eu
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI

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.

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.

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.

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.