[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