All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stecklina, Julian" <jsteckli@amazon.de>
To: "jwadams@google.com" <jwadams@google.com>,
	"bsingharora@gmail.com" <bsingharora@gmail.com>
Cc: "deepa.srinivasan@oracle.com" <deepa.srinivasan@oracle.com>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	"jmattson@google.com" <jmattson@google.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"pradeep.vincent@oracle.com" <pradeep.vincent@oracle.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"khalid.aziz@oracle.com" <khalid.aziz@oracle.com>,
	"joao.m.martins@oracle.com" <joao.m.martins@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: Tue, 25 Sep 2018 14:12:57 +0000	[thread overview]
Message-ID: <1537884777.23693.27.camel@amazon.de> (raw)
In-Reply-To: <20180923023315.GF8537@350D>

On Sun, 2018-09-23 at 12:33 +1000, Balbir Singh wrote:
> > And in so 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).
> 
> I see and there is no way for gadgets to invoke this path from
> user space to make their speculation successful? We still have to
> flush L1, indepenedent of whether XPFO is enabled or not right?

Yes. And even with XPFO and L1 cache flushing enabled, there are more
steps that need to be taken to reliably guard against information leaks
using speculative execution.

Specifically, I'm looking into making certain allocations in the Linux
kernel process-local to hide even more memory from prefetching.

Another puzzle piece is co-scheduling support that is relevant for
systems with enabled hyperthreading: https://lwn.net/Articles/764461/

Julian
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

  reply	other threads:[~2018-09-25 14:13 UTC|newest]

Thread overview: 52+ 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
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 [this message]
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=1537884777.23693.27.camel@amazon.de \
    --to=jsteckli@amazon.de \
    --cc=ak@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bsingharora@gmail.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=jwadams@google.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=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.