Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI
To: Nadav Amit <namit@vmware.com>, linux-kernel@vger.kernel.org
References: <20180114201306.3554-1-namit@vmware.com>
Cc: luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
        hpa@zytor.com, x86@kernel.org, nadav.amit@gmail.com, w@1wt.eu
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <57a8fa6b-a1d1-d440-ce13-b1d06d265584@linux.intel.com>
Date: Mon, 15 Jan 2018 11:49:19 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180114201306.3554-1-namit@vmware.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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.