[MODERATED] Re: LVI

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