Re: [Qemu-devel] [PATCH 0/3] virtio: Eliminate "exit(1)" upon invalid request in virtio-blk and virtio-scsi

[Kevin Wolf]

Am 24.04.2014 um 09:55 hat Michael S. Tsirkin geschrieben:
> On Thu, Apr 24, 2014 at 09:15:25AM +0200, Markus Armbruster wrote:
> > "Michael S. Tsirkin" <address@hidden> writes:
> > 
> > > On Wed, Apr 23, 2014 at 11:22:51AM +0800, Fam Zheng wrote:
> > >> This series is a step towards getting rid of such code,
> > >
> > > Sure, incremental patches are good. At this point I think it's
> > > a good idea to clearly mark this as RFC - I don't think we should yet 
> > > merge
> > > this upstream until the solution is a bit more complete.
> > >
> > > Changing virtio is the easy part though, so I'm not sure it's a good
> > > idea to start there.
> > 
> > Does this series hinder work on the harder parts in any way?  Does it
> > pick a specific solution that may not work for the harder parts?
> > 
> > If not, then I can't see what keeping it out of tree can buy us.
> 
> Less code churn.  It's more code apparently for no real benefit
> since buggy drivers will still abort qemu.

Depends on what bugs the driver has.

Not fixing bugs because there are still other bugs that can crash qemu
isn't productive. If we went this way consistently, we would reject any
bug fix unless the commit message contains a mathematical proof that all
of qemu is correct now. We could stop development right now.

This is an easy bug to fix, we have the patches, so let's just fix it.
The solution won't become any better by waiting for independent fixes.

> Making nested virt work well is a big project, I'd like to see some
> progress on the hard parts before trying to address easy corner cases
> like this one.

Addressing the easy parts doesn't make the hard parts any harder.

> > >> Regarding the malicious guest, protecting D.O.S. attack is also
> > >> valuable, isn't
> > >> it?
> > >> 
> > >> Thanks,
> > >> Fam
> > >
> > > Guest denying itself a service? I'm not sure why it's valuable.
> > 
> > If I remember correctly, the DOS involved passthrough of a virtual
> > device to a nested guest or something like that.
> >  Guest killing itself
> > is unexciting, nested guest killing its host qualifies as DOS.  I guess
> > our current answer to that is "don't do that then".
> 
> Yes.  virtio doesn't support that for a variety of other reasons,
> one of which is that it doesn't go through an mmu.
> Now, before someone sends a trivial patch converting it to
> mmu aware calls, that's not yet possible without teaching vhost
> and dataplane about MMU.

Nested virt is really just one example for a userspace virtio driver.
Userspace shouldn't be able to kill the whole guest.

Kevin