qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] virtio: Eliminate "exit(1)" upon invalid re


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/3] virtio: Eliminate "exit(1)" upon invalid request in virtio-blk and virtio-scsi
Date: Fri, 25 Apr 2014 08:29:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> writes:

> 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.

Exactly.  Thanks for putting it so pithily; I rather like that :)

Fam's work is an incremental step towards rectifying a certain kind of
mistake in device model code.  Nested virt just happens to be hurt by
these mistakes.

Making it depend on the big, complex, ambitious project like "make
nested virt work" is *backwards*, and all that can achieve is moving the
problem from "incrementally solvable" towards "boil the ocean".

>> > > >> 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.

Really?  Why is it fundamentally impossible to put the device into an
error state when we detect invalid device use by the guest?  Honest
question; please excuse my ignorance here...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]