Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Woodhouse, David" <dwmw@amazon.co.uk>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Cc: "juerg.haefliger@hpe.com" <juerg.haefliger@hpe.com>,
	"deepa.srinivasan@oracle.com" <deepa.srinivasan@oracle.com>,
	"jmattson@google.com" <jmattson@google.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
	"pradeep.vincent@oracle.com" <pradeep.vincent@oracle.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"khalid.aziz@oracle.com" <khalid.aziz@oracle.com>,
	"kanth.ghatraju@oracle.com" <kanth.ghatraju@oracle.com>,
	"liran.alon@oracle.com" <liran.alon@oracle.com>,
	"keescook@google.com" <keescook@google.com>,
	"jsteckli@os.inf.tu-dresden.de" <jsteckli@os.inf.tu-dresden.de>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"chris.hyser@oracle.com" <chris.hyser@oracle.com>,
	"tyhicks@canonical.com" <tyhicks@canonical.com>,
	"john.haxby@oracle.com" <john.haxby@oracle.com>,
	"jcm@redhat.com" <jcm@redhat.com>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)
Date: Fri, 31 Aug 2018 09:43:47 +0100	[thread overview]
Message-ID: <1535705027.3085.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <1534801939.10027.24.camel@amazon.co.uk>

On Mon, 2018-08-20 at 21:52 +0000, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> > 
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe I'm missing something really fundamental, and
> > the XPFO patches do something else than what I think they do, or my
> > "hey, let's use our Meltdown code" idea has some fundamental
> > weakness
> > that I'm missing.
> 
> The interesting part is taking the user (and other) pages out of the
> kernel's 1:1 physmap.
> 
> It's the *kernel* we don't want being able to access those pages,
> because of the multitude of unfixable cache load gadgets.

A long time ago, I gave a talk about precisely this at OLS (2005 I
think).  On PA-RISC we have a problem with inequivalent aliasing in the
 page cache (same physical page with two different virtual addresses
modulo 4MB) which causes a machine check if it occurs. 
Architecturally, PA can move into the cache any page for which it has a
mapping and the kernel offset map of every page causes an inequivalency
if the same page is in use in user space.  Of course, practically the
caching machinery is too busy moving in and out pages we reference to
have an interest in speculating on other pages it has a mapping for, so
it almost never (the almost being a set of machine checks we see very
occasionally in the latest and most aggressively cached and speculating
CPUs).  If this were implemented, we'd be interested in using it.

James