On Tue, Jan 31, 2023 at 04:14:29PM +0100, Christophe de Dinechin wrote: > Finally, security considerations that apply irrespective of whether the > platform is confidential or not are also outside of the scope of this > document. This includes topics ranging from timing attacks to social > engineering. Why are timing attacks by hypervisor on the guest out of scope? > </doc> > > Feel free to comment and reword at will ;-) > > > 3/ PCI-as-a-threat: where does that come from > > Isn't there a fundamental difference, from a threat model perspective, > between a bad actor, say a rogue sysadmin dumping the guest memory (which CC > should defeat) and compromised software feeding us bad data? I think there > is: at leats inside the TCB, we can detect bad software using measurements, > and prevent it from running using attestation. In other words, we first > check what we will run, then we run it. The security there is that we know > what we are running. The trust we have in the software is from testing, > reviewing or using it. > > This relies on a key aspect provided by TDX and SEV, which is that the > software being measured is largely tamper-resistant thanks to memory > encryption. In other words, after you have measured your guest software > stack, the host or hypervisor cannot willy-nilly change it. > > So this brings me to the next question: is there any way we could offer the > same kind of service for KVM and qemu? The measurement part seems relatively > easy. Thetamper-resistant part, on the other hand, seems quite difficult to > me. But maybe someone else will have a brilliant idea? > > So I'm asking the question, because if you could somehow prove to the guest > not only that it's running the right guest stack (as we can do today) but > also a known host/KVM/hypervisor stack, we would also switch the potential > issues with PCI, MSRs and the like from "malicious" to merely "bogus", and > this is something which is evidently easier to deal with. Agree absolutely that's much easier. > I briefly discussed this with James, and he pointed out two interesting > aspects of that question: > > 1/ In the CC world, we don't really care about *virtual* PCI devices. We > care about either virtio devices, or physical ones being passed through > to the guest. Let's assume physical ones can be trusted, see above. > That leaves virtio devices. How much damage can a malicious virtio device > do to the guest kernel, and can this lead to secrets being leaked? > > 2/ He was not as negative as I anticipated on the possibility of somehow > being able to prevent tampering of the guest. One example he mentioned is > a research paper [1] about running the hypervisor itself inside an > "outer" TCB, using VMPLs on AMD. Maybe something similar can be achieved > with TDX using secure enclaves or some other mechanism? Or even just secureboot based root of trust? -- MST
