Anthony Liguori wrote: > Joanna Rutkowska wrote: >> Avi Kivity wrote: >> >>> On 12/07/2009 07:09 PM, Joanna Rutkowska wrote: >>> >>>>> Also, you can use qemu to provide the backends to a Xen PV guest >>>>> (see -M >>>>> xenpv). The effect is that you are moving that privileged code >>>>> from the >>>>> kernel (netback/blkback) to userspace (qemu -M xenpv). >>>>> >>>>> In general, KVM tends to keep code in userspace unless absolutely >>>>> necessary. That's a fundamental difference from Xen which tends to do >>>>> the opposite. >>>>> >>>>> >>>> But the difference is that in case of Xen one can *easily* move the >>>> backends to small unprivileged VMs. In that case it doesn't matter the >>>> code is in kernel mode, it's still only in an unprivileged domain. >>>> >>>> >>> They're not really unprivileged, one can easily program the dma >>> controller of their assigned pci card to read and write arbitrary host >>> memory. >>> >>> >> >> That's not true if you use VT-d. >> > > I'm skeptical that VT-d in its current form provides protection against > a malicious guest. The first problem is interrupt delivery. I don't > think any hypervisor has really put much thought into mitigating > interrupt storms as a DoS. I think there are a number of nasty things > that can be done here. > Intel VT-d v1 doesn't support interrupt remapping, so I'm sure you're right here. But DoS attack is a different thing then a system subversion (think malware) attack. Of course which one you fear more would depend on your threat model. > Even if you assume that there aren't flaws in VT-d wrt malicious guests, > we have generations of hardware that have not been designed to be robust > against malicious operating systems. There are almost certainly untold > numbers of exploitable hardware bugs that can be used to do all sorts of > terrible things to the physical system. > Perhaps, although so far nobody presented a software-only VT-d escape attack. I think it's reasonable to assume some maniacs would discover a one or two in the coming years. Still, probably order of magnitude less likely than a Linux kernel overflow. > VT-d protects against DMA access, but there's still plenty of things a > malicious PCI device can do to harm the physical system. I'm sure you > could easily program a PCI device to flood the bus which effectively > mounts a DoS against other domains. There is no mechanism to arbitrate > this today. It's really a dramatically different model from a security > perspective. > Agree, there are lots of DoS possibilities. It's just that for me, personally, they are not in the threat model. joanna.
Attachment:
signature.asc
Description: OpenPGP digital signature
