[MODERATED] Re: LVI

Paolo Bonzini <[email protected]> Wed, 20 Nov 2019 10:52:29 +0100
Newsgroups org.kernel.lore.historical-speck
Message-ID <[email protected]>
On 19/11/19 19:27, speck for Josh Poimboeuf wrote:
>> 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.

It seems feasible to use a guest framebuffer (which is refreshed, and D
bits are cleared, quite a few times per second) to cause PML(*) vmexits.

> 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...
> 
> 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.
> 
> For L1TF-affected systems would it be feasible to move the vmenter
> flushing to vmexit?  Or would we need both?

It would need both, the vmenter flushing is needed to hide contents from
the host kernel to the guest.  Adding a flush on vmexit would be
horrible not just for performance but also latency.

Paolo

(*) page modification log - trigger a vmexit every 512 dirty pages