linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Liran Alon <liran.alon@oracle.com>,
	deepa.srinivasan@oracle.com, linux-mm <linux-mm@kvack.org>,
	juerg.haefliger@hpe.com, Khalid Aziz <khalid.aziz@oracle.com>,
	chris.hyser@oracle.com, Tyler Hicks <tyhicks@canonical.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Kees Cook <keescook@google.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jon Masters <jcm@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	kanth.ghatraju@oracle.com, joao.m.martins@oracle.com,
	Jim Mattson <jmattson@google.com>,
	pradeep.vincent@oracle.com, Andi Kleen <ak@linux.intel.com>,
	John Haxby <john.haxby@oracle.com>,
	jsteckli@os.inf.tu-dresden.de,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)
Date: Mon, 20 Aug 2018 14:48:51 -0700	[thread overview]
Message-ID: <CA+55aFxZCyVZc4ZpRyZ3uDyakRSOG_=2XvnwMo4oejpsieF9=A@mail.gmail.com> (raw)
In-Reply-To: <20180820212556.GC2230@char.us.oracle.com>

On Mon, Aug 20, 2018 at 2:26 PM Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>
> See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which was posted
> way back in in 2016..

Ok, so my gut feel is that the above was reasonable within the context
of 2016, but that the XPFO model is completely pointless and wrong in
the post-Meltdown world we now live in.

Why?

Because with the Meltdown patches, we ALREADY HAVE the isolated page
tables that XPFO tries to do.

They are just the normal user page tables.

So don't go around doing other crazy things.

All you need to do is to literally:

 - before you enter VMX mode, switch to the user page tables

 - when you exit, switch back to the kernel page tables

don't do anything else.  You're done.

Now, this is complicated a bit by the fact that in order to enter VMX
mode with the user page tables, you do need to add the VMX state
itself to those user page tables (and add the actual trampoline code
to the vmenter too).

So it does imply we need to slightly extend the user mapping with a
few new patches, but that doesn't sound bad.

In fact, it sounds absolutely trivial to me.

The other thing you want to do is is the trivial optimization of "hey.
we exited VMX mode due to a host interrupt", which would look like
this:

 * switch to user page tables in order to do vmenter
 * vmenter
 * host interrupt happens
    - switch to kernel page tables to handle irq
    - do_IRQ etc
    - switch back to user page tables
    - iret
 * switch to kernel page tables because the vmenter returned

so you want to have some trivial short-circuiting of that last "switch
to user page tables and back" dance. It may actually be that we don't
even need it, because the irq code may just be looking at what *mode*
we were in, not what page tables we were in. I looked at that code
back in the meltdown days, but that's already so last-year now that we
have all these _other_ CPU bugs we handled.

But other than small details like that, doesn't this "use our Meltdown
user page table" sound like the right thing to do?

And note: no new VM code or complexity. None. We already have the
"isolated KVM context with only pages for the KVM process" case
handled.

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.

              Linus

  reply	other threads:[~2018-08-20 21:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20 21:25 Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) Konrad Rzeszutek Wilk
2018-08-20 21:48 ` Linus Torvalds [this message]
     [not found]   ` <1534801939.10027.24.camel@amazon.co.uk>
2018-08-20 22:18     ` Kees Cook
2018-08-20 22:27     ` Linus Torvalds
2018-08-20 22:35       ` Tycho Andersen
2018-08-20 22:59         ` Dave Hansen
2018-08-20 23:14           ` David Woodhouse
2018-08-20 23:26             ` Dave Hansen
2018-08-20 23:38               ` Linus Torvalds
2018-08-21  9:57       ` David Woodhouse
2018-08-21 14:01         ` Liran Alon
2018-08-21 14:22           ` David Woodhouse
2018-08-21 23:04             ` Liran Alon
2018-08-30 16:00       ` Julian Stecklina
2018-08-31 15:26         ` Tycho Andersen
2018-09-01 21:38         ` Linus Torvalds
2018-09-03 14:51           ` Julian Stecklina
2018-09-12 15:37             ` Julian Stecklina
2018-09-13  6:11               ` Juerg Haefliger
2018-09-17 10:01                 ` Julian Stecklina
2018-09-17 10:19                   ` Tycho Andersen
2018-09-17 13:27                   ` Christoph Hellwig
2018-09-14 17:06               ` Khalid Aziz
2018-09-17  9:51                 ` Julian Stecklina
2018-09-18 23:00                   ` Khalid Aziz
2018-09-24 14:45                     ` Stecklina, Julian
2018-10-15  8:07                       ` Khalid Aziz
2018-10-24 11:00                         ` Khalid Aziz
2018-10-24 15:00                           ` Tycho Andersen
2018-09-03 15:26           ` Andi Kleen
2018-09-04  9:37             ` Julian Stecklina
     [not found]           ` <CACfEFw_h5uup-anKZwfBcWMJB7gHxb9NEPTRSUAY0+t11RiQbg@mail.gmail.com>
2018-09-03 15:36             ` Andi Kleen
2018-09-07 21:30         ` Khalid Aziz
2018-08-31  8:43     ` James Bottomley
2018-09-19  1:03     ` Balbir Singh
2018-09-19 15:43       ` Jonathan Adams
2018-09-23  2:33         ` Balbir Singh
2018-09-25 14:12           ` Stecklina, Julian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFxZCyVZc4ZpRyZ3uDyakRSOG_=2XvnwMo4oejpsieF9=A@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=ak@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=chris.hyser@oracle.com \
    --cc=deepa.srinivasan@oracle.com \
    --cc=dwmw@amazon.co.uk \
    --cc=jcm@redhat.com \
    --cc=jmattson@google.com \
    --cc=joao.m.martins@oracle.com \
    --cc=john.haxby@oracle.com \
    --cc=jsteckli@os.inf.tu-dresden.de \
    --cc=juerg.haefliger@hpe.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=keescook@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=khalid.aziz@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liran.alon@oracle.com \
    --cc=pradeep.vincent@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=tyhicks@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).