From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: Cache load gadgets
Date: Fri, 17 Aug 2018 22:33:40 -0400 [thread overview]
Message-ID: <20180818023339.GB29487@char.us.oracle.com> (raw)
In-Reply-To: <4be96a4b-ee6f-fd51-21cb-f3c94d4ec39e@alien8.de>
On Fri, Aug 17, 2018 at 10:00:13PM +0200, speck for Julian Stecklina wrote:
> On 08/17/2018 11:18 AM, speck for Paolo Bonzini wrote:
> > On 17/08/2018 11:11, speck for Julian Stecklina wrote:
> >> L1TF in combination with a suitable cache load gadget on a HT-enabled
> >> system is very practical. As we are not going to fix pure cache load
> >> gadgets in the kernel, this leaves two options for the security minded:
> >> a) Turn off HT and take a large performance hit for some workloads or b)
> >> carry their own patches on top of upstream.
> >>
> >> I guess there are quite some people in the b) camp at the moment.
> > KVM is special in that it has the EPT variant of L1TF, and fixing the
> > most blatant cache load gadgets there is probably feasible. Doing it in
> > general is hard and unmaintainable though. At least we should use
> > sparse static analysis to track those tainted values.
>
> In general, I agree. For our usecase, we would also need to fix parts of
> VFIO and maybe other common system call entry paths. It's just
> labor-intense and error prone.
>
> The last days, I have been experimenting with making certain KVM memory
> allocations process-local in the kernel, so they cannot be pulled in
> with cache load gadgets from other processes in the first place. It
> looks promising so far. Of course, this doesn't address the big linear
> memory mapping of physical memory, but it's a start.
Just in case you are not aware this was posted some time ago:
https://marc.info/?l=linux-kernel&m=151923574116661&w=2
Any chance you could drop a git bundle of what you have done so far?
>
> I'm also hoping someone picks up the speculative load hardening compiler
> pass in clang and fixes it for the kernel. Maybe the performance impact
> is not so bad, if some hot code paths are manually checked. The problem
> is mostly that they assume that RSP is positive, which is obviously not
> the case in the kernel, but it looks fixable:
> https://docs.google.com/document/d/1wwcfv3UV9ZnZVcGiGuoITT_61e_Ko3TmoCS3uXLcJR0/edit#heading=h.phdehs44eom6
>
Let me ask the compiler folks in Oracle.
>
> Julian
>
>
next prev parent reply other threads:[~2018-08-18 2:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 13:53 [MODERATED] Cache load gadgets David Woodhouse
2018-08-08 14:53 ` [MODERATED] " Andi Kleen
2018-08-08 15:34 ` Josh Poimboeuf
2018-08-08 16:50 ` Andi Kleen
2018-08-08 17:22 ` Josh Poimboeuf
2018-08-09 19:01 ` Thomas Gleixner
2018-08-13 15:17 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-08-13 16:40 ` David Woodhouse
2018-08-13 19:27 ` Luck, Tony
2018-08-14 9:48 ` Julian Stecklina
2018-08-14 15:00 ` Andi Kleen
2018-08-17 9:11 ` Julian Stecklina
2018-08-17 9:18 ` Paolo Bonzini
2018-08-17 9:58 ` Norbert Manthey
2018-08-17 20:00 ` Julian Stecklina
2018-08-18 2:33 ` Konrad Rzeszutek Wilk [this message]
2018-08-13 17:23 ` Josh Poimboeuf
2018-08-13 18:59 ` Greg KH
2018-08-13 19:54 ` Josh Poimboeuf
2018-08-13 20:20 ` Linus Torvalds
2018-08-13 20:48 ` Josh Poimboeuf
2018-08-13 20:56 ` Linus Torvalds
2018-08-13 21:13 ` David Woodhouse
2018-08-13 21:23 ` Josh Poimboeuf
2018-08-13 21:41 ` Linus Torvalds
2018-08-13 22:10 ` Josh Poimboeuf
2018-08-13 22:20 ` Linus Torvalds
2018-08-09 19:00 ` Thomas Gleixner
2018-08-09 19:20 ` [MODERATED] " David Woodhouse
2018-08-13 16:29 ` Paolo Bonzini
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=20180818023339.GB29487@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=speck@linutronix.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).