[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2018 08:34:31 -0700
From: Jonathan Adams <jwadams@...gle.com>
To: bsingharora@...il.com
Cc: dwmw@...zon.co.uk, torvalds@...ux-foundation.org, konrad.wilk@...cle.com,
juerg.haefliger@....com, deepa.srinivasan@...cle.com,
Jim Mattson <jmattson@...gle.com>, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, boris.ostrovsky@...cle.com, linux-mm@...ck.org,
tglx@...utronix.de, joao.m.martins@...cle.com, pradeep.vincent@...cle.com,
ak@...ux.intel.com, khalid.aziz@...cle.com, kanth.ghatraju@...cle.com,
liran.alon@...cle.com, keescook@...gle.com, jsteckli@...inf.tu-dresden.de,
kernel-hardening@...ts.openwall.com, chris.hyser@...cle.com,
tyhicks@...onical.com, john.haxby@...cle.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 Tue, Sep 18, 2018 at 6:03 PM Balbir Singh <bsingharora@...il.com> wrote:
> 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?
>
> SMAP protects against kernel accesses to non-PRIV (i.e. userspace)
mappings, but that isn't relevant to what's being discussed here.
Davis is talking about the kernel Direct Map, which is a PRIV (i.e. kernel)
mapping of all physical memory on the system, at VA = (base + PA). Since
this mapping exists for all physical addresses, speculative load gadgets
(and the processor's prefetch mechanism, etc.) can load arbitrary data even
if it is only otherwise mapped into user space.
XPFO fixes this by unmapping the Direct Map translations when the page is
allocated as a user page. The mapping is only restored:
1. temporarily re-if the kernel needs direct access to the page (i.e. to
zero it, access it from a device driver, etc),
2. when the page is freed
And in to doing, significantly reduces the amount of non-kernel data
vulnerable to speculative execution attacks against the kernel. (and
reduces what data can be loaded into the L1 data cache while in kernel
mode, to be peeked at by the recent L1 Terminal Fault vulnerability).
Does that make sense?
Cheers,
- jonathan
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
