From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: kernel-hardening@lists.openwall.com,
Liran Alon <liran.alon@oracle.com>,
Deepa Srinivasan <deepa.srinivasan@oracle.com>,
linux-mm@kvack.org, juerg.haefliger@hpe.com,
khalid.aziz@oracle.com, chris.hyser@oracle.com,
tyhicks@canonical.com, dwmw@amazon.co.uk, keescook@google.com,
andrew.cooper3@citrix.com, jcm@redhat.com,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Kanth <kanth.ghatraju@oracle.com>,
Joao Martins <joao.m.martins@oracle.com>,
jmattson@google.com, pradeep.vincent@oracle.com,
Linus Torvalds <torvalds@linux-foundation.org>,
ak@linux.intel.com, john.haxby@oracle.com,
jsteckli@os.inf.tu-dresden.de
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)
Date: Mon, 20 Aug 2018 17:25:56 -0400 [thread overview]
Message-ID: <20180820212556.GC2230@char.us.oracle.com> (raw)
Hi!
See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which was posted
way back in in 2016..
In the last couple of months there has been a slew of CPU issues that have complicated
a lot of things. The latest - L1TF - is still fresh in folks's mind and it is
especially acute to virtualization workloads.
As such a bunch of various folks from different cloud companies (CCed) are looking
at a way to make Linux kernel be more resistant to hardware having these sort of
bugs.
In particular we are looking at a way to "remove as many mappings from the global
kernel address space as possible. Specifically, while being in the
context of process A, memory of process B should not be visible in the
kernel." (email from Julian Stecklina). That is the high-level view and
how this could get done, well, that is why posting this on
LKML/linux-hardening/kvm-devel/linux-mm to start the discussion.
Usually I would start with a draft of RFC patches so folks can rip it apart, but
thanks to other people (Juerg thank you!) it already exists:
(see https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1222756.html)
The idea would be to extend this to:
1) Only do it for processes that run under CPUS which are in isolcpus list.
2) Expand this to be a per-cpu page tables. That is each CPU has its own unique
set of pagetables - naturally _START_KERNEL -> __end would be mapped but the
rest would not.
Thoughts? Is this possible? Crazy? Better ideas?
next reply other threads:[~2018-08-20 21:26 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 21:25 Konrad Rzeszutek Wilk [this message]
2018-08-20 21:48 ` Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) Linus Torvalds
2018-08-20 21:52 ` Woodhouse, David
2018-08-20 22:18 ` Kees Cook
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-01 22:33 ` Wes Turner
2018-09-03 15:36 ` Andi Kleen
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: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-09-24 14:45 ` Stecklina, Julian
2018-10-15 8:07 ` Khalid Aziz
2018-10-15 8:07 ` Khalid Aziz
2018-10-24 11:00 ` Khalid Aziz
2018-10-24 11:00 ` Khalid Aziz
2018-10-24 15:00 ` Tycho Andersen
2018-10-24 15:00 ` Tycho Andersen
2018-09-03 15:26 ` Andi Kleen
2018-09-04 9:37 ` Julian Stecklina
2018-09-04 9:37 ` Julian Stecklina
2018-09-07 21:30 ` Khalid Aziz
2018-08-31 8:43 ` James Bottomley
2018-08-31 8:43 ` James Bottomley
2018-09-19 1:03 ` Balbir Singh
2018-09-19 1:03 ` Balbir Singh
2018-09-19 15:34 ` Jonathan Adams
2018-09-19 15:38 ` Jonathan Adams
2018-09-19 15:43 ` Jonathan Adams
2018-09-23 2:33 ` Balbir Singh
2018-09-25 14:12 ` Stecklina, Julian
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=20180820212556.GC2230@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--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=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=torvalds@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.