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

[Michael S. Tsirkin]

On Thu, Apr 24, 2014 at 12:43:56PM +0200, Kevin Wolf wrote:
> 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

Without an MMIO this is fundamentally unavoidable.