historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: LVI
Date: Tue, 19 Nov 2019 19:26:20 +0000	[thread overview]
Message-ID: <61368feb-3f39-677c-1f8d-90fdb0325070@citrix.com> (raw)
In-Reply-To: <20191119182752.xh5e6x733nnhjwo5@treble>

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On 19/11/2019 18:27, speck for Josh Poimboeuf wrote:
> On Tue, Nov 19, 2019 at 05:51:40PM +0000, speck for Andrew Cooper wrote:
>> On 19/11/2019 17:40, speck for Josh Poimboeuf wrote:
>>> Hi,
>>>
>>> What kernel changes (if any) are needed for LVI?  I haven't seen any
>>> discussion here.
>> I have similar questions when it comes to virt.  For one, EPT A/D bits
>> undermine any action the guest kernel takes to protect itself.
>>
>> Given various pieces of academic literature on gaming the paging-out
>> algorithm, I'm not inclined to take the bet that an attacker couldn't
>> control EPT A/D bits to their advantage.
> Hm, so IIUC, that would open up every load in the guest to a potential
> attack, if it has gadgets after it?  That does sound bad...

Yes.  In the face of a malicious hypervisor playing with A/D bits, it
degrades to the SGX case of requiring an lfence between every memory
operand which may alias modulo 4k.

Of course, this case isn't interesting as the hypervisor can just read
the data it wants, and there are no Intel parts with encrypted VM
technology yet, but it is worth keeping sight of the worst case when
reasoning about how controllable A/D bits are.

In practice, it will depend largely on whether guest userspace can
influence migration and/or host paging enough to do anything useful.

> If the A/D bit control is feasible then it sounds like we'd need an
> L1TF-like flushing mitigation after vmexit?  That would protect the host
> kernel too.

EPT A/D is an optional feature, available in Broadwell and later, and
can be turned off.

The practical impact of this would be forcing these parts to use legacy
logdirty mechanisms, rather than the hardware Page Modification Logging
feature, whose implementation depends on EPT A/D being active.

That said, there may be issues speculating past an EPT_VIOLATION, which
may also play a part here (and I could probably do with a refresher on
which exits have which serialising properties, etc).

~Andrew


  reply	other threads:[~2019-11-19 19:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 17:40 [MODERATED] LVI Josh Poimboeuf
2019-11-19 17:51 ` [MODERATED] LVI Andrew Cooper
2019-11-19 18:27   ` Josh Poimboeuf
2019-11-19 19:26     ` Andrew Cooper [this message]
2019-11-20  9:52     ` Paolo Bonzini
2019-11-19 18:12 ` Greg KH
2019-11-19 18:21   ` Josh Poimboeuf
2019-11-19 18:46     ` Greg KH
2019-11-19 18:21   ` Paolo Bonzini
2019-11-19 18:22 ` Andrew Cooper
2019-11-19 18:27   ` Josh Poimboeuf
2019-11-19 18:36     ` Luck, Tony
2019-11-20 17:02       ` Greg KH
2019-11-19 18:39     ` Andrew Cooper
2019-11-19 21:00       ` Josh Poimboeuf
2019-11-19 21:03         ` Josh Poimboeuf
2019-11-20 14:11           ` Andrew Cooper
2019-11-20  8:04 ` Peter Zijlstra
2019-11-20  9:49   ` Andrew Cooper
2019-11-20 17:13 ` Josh Poimboeuf
2019-11-20 17:25   ` Greg KH
2019-11-20 17:29     ` Tyler Hicks
2019-11-20 17:30     ` Andrew Cooper
2019-11-20 17:46       ` Greg KH
2019-11-20 19:09     ` Peter Zijlstra
2019-11-20 19:19       ` Greg KH
2019-11-21  0:50         ` LVI Thomas Gleixner
2019-11-21 13:45           ` [MODERATED] LVI Greg KH
2019-11-26  0:54 ` Andi Kleen
2019-11-26 10:37   ` Greg KH
2019-11-26 18:23     ` Andi Kleen
2019-11-27  7:38       ` Greg KH
2019-11-26 10:55   ` Paolo Bonzini
2019-11-26 18:28     ` Andi Kleen

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=61368feb-3f39-677c-1f8d-90fdb0325070@citrix.com \
    --to=andrew.cooper3@citrix.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 NNTP newsgroup(s).