On Tue, 04/22 22:12, Michael S. Tsirkin wrote: > On Tue, Apr 22, 2014 at 04:55:14PM +0800, Fam Zheng wrote: > > Today, buggy or malicous guests that submit invalid requests can cause > > QEMU's > > exit with an error message, which is not friendly to neither user/admin nor > > guest. When passing through a virtio device to a nested vm, there is also an > > D.O.S. vulnerability. > > > > This series adds "broken" flag to VirtIODevice and allows device emulation > > code > > to set it if invalid data from guest is seen, and then decide what to do > > with > > the (invalid and/or further) requests, by checking the status of the flag. > > > > Upon device reset, "broken" is cleared and the device comes back to normal > > again. > > > > In the patch 2 and 3, virtio-blk and virtio-scsi will just set the broken > > flag, > > and stop poping requests from virt queue. In other words, the guest will > > find > > the device inresponsive, the only way it can do is resetting the device. > > > > Other virtio device types, as well as virtqueue core code, have more > > exit(1)'s > > to be converted, but could be done on top of this. > > > > Thanks, > > Fam > > > > > It still seems trivially easy for a buggy guest to cause qemu to > abort, e.g. by supplying an invalid physical address to write to. > > OTOH it seems possible that killing the malicious guest early reduces our > security attack surface. >
IMO, a buggy guest doing wrong operations is not necessarily the end of world for QEMU, we shouldn't tear down the whole process because of invalid input. This series is a step towards getting rid of such code, if there are trivial ways to abort qemu from a guest bug, then they may be candidates to improve as well. Regarding the malicious guest, protecting D.O.S. attack is also valuable, isn't it? Thanks, Fam