[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180919010337.GC8537@350D>
Date: Wed, 19 Sep 2018 11:03:37 +1000
From: Balbir Singh <bsingharora@...il.com>
To: "Woodhouse, David" <dwmw@...zon.co.uk>
Cc: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
"juerg.haefliger@....com" <juerg.haefliger@....com>,
"deepa.srinivasan@...cle.com" <deepa.srinivasan@...cle.com>,
"jmattson@...gle.com" <jmattson@...gle.com>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"joao.m.martins@...cle.com" <joao.m.martins@...cle.com>,
"pradeep.vincent@...cle.com" <pradeep.vincent@...cle.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"khalid.aziz@...cle.com" <khalid.aziz@...cle.com>,
"kanth.ghatraju@...cle.com" <kanth.ghatraju@...cle.com>,
"liran.alon@...cle.com" <liran.alon@...cle.com>,
"keescook@...gle.com" <keescook@...gle.com>,
"jsteckli@...inf.tu-dresden.de" <jsteckli@...inf.tu-dresden.de>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
"chris.hyser@...cle.com" <chris.hyser@...cle.com>,
"tyhicks@...onical.com" <tyhicks@...onical.com>,
"john.haxby@...cle.com" <john.haxby@...cle.com>,
"jcm@...hat.com" <jcm@...hat.com>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs
in mind (for KVM to isolate its guests per CPU)
On Mon, Aug 20, 2018 at 09:52:19PM +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.
I am missing why we need this since the kernel can't access
(SMAP) unless we go through to the copy/to/from interface
or execute any of the user pages. Is it because of the dependency
on the availability of those features?
Balbir Singh.
Powered by blists - more mailing lists