"Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes: > On Tue, Oct 20, 2020 at 09:46:11AM +0200, Vitaly Kuznetsov wrote: >> "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes: >> >> > == Background / Problem == >> > >> > There are a number of hardware features (MKTME, SEV) which protect guest >> > memory from some unauthorized host access. The patchset proposes a purely >> > software feature that mitigates some of the same host-side read-only >> > attacks. >> > >> > >> > == What does this set mitigate? == >> > >> > - Host kernel ”accidental” access to guest data (think speculation) >> > >> > - Host kernel induced access to guest data (write(fd, &guest_data_ptr, len)) >> > >> > - Host userspace access to guest data (compromised qemu) >> > >> > - Guest privilege escalation via compromised QEMU device emulation >> > >> > == What does this set NOT mitigate? == >> > >> > - Full host kernel compromise. Kernel will just map the pages again. >> > >> > - Hardware attacks >> > >> > >> > The second RFC revision addresses /most/ of the feedback. >> > >> > I still didn't found a good solution to reboot and kexec. Unprotect all >> > the memory on such operations defeat the goal of the feature. Clearing up >> > most of the memory before unprotecting what is required for reboot (or >> > kexec) is tedious and error-prone. >> > Maybe we should just declare them unsupported? >> >> Making reboot unsupported is a hard sell. Could you please elaborate on >> why you think that "unprotect all" hypercall (or rather a single >> hypercall supporting both protecting/unprotecting) defeats the purpose >> of the feature? > > If guest has some data that it prefers not to leak to the host and use the > feature for the purpose, share all the memory to get through reboot is a > very weak point. > My point that if it knows that there's something sensitive in its memory it should clean it up even today without your feature before rebooting to an unknown target. >> >> clean up *all* its memory upon reboot, however: >> - It may only clean up the most sensitive parts. This should probably be >> done even without this new feature and even on bare metal (think about >> next boot target being malicious). >> - The attack window shrinks significantly. "Speculative" bugs require >> time to exploit and it will only remain open until it boots up again >> (few seconds). > > Maybe it would be cleaner to handle reboot in userspace? If we got the VM > rebooted, just reconstruct it from scratch as if it would be new boot. We are definitely not trying to protect against malicious KVM so maybe we can do the cleanup there (when protection was enabled) so we can unprotect everything without risk of a leak? -- Vitaly
