qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] block: Add option to use driver whitelist even in tools


From: Daniel P . Berrangé
Subject: Re: [PATCH] block: Add option to use driver whitelist even in tools
Date: Mon, 12 Jul 2021 16:44:08 +0100
User-agent: Mutt/2.0.7 (2021-05-04)

On Mon, Jul 12, 2021 at 10:18:30AM +0200, Kevin Wolf wrote:
> Am 09.07.2021 um 19:45 hat Eric Blake geschrieben:
> > On Fri, Jul 09, 2021 at 06:41:41PM +0200, Kevin Wolf wrote:
> > > Currently, the block driver whitelists are only applied for the system
> > > emulator. All other binaries still give unrestricted access to all block
> > > drivers. There are use cases where this made sense because the main
> > > concern was avoiding customers running VMs on less optimised block
> > > drivers and getting bad performance. Allowing the same image format e.g.
> > > as a target for 'qemu-img convert' is not a problem then.
> > > 
> > > However, if the concern is the supportability of the driver in general,
> > > either in full or when used read-write, not applying the list driver
> > > whitelist in tools doesn't help - especially since qemu-nbd and
> > > qemu-storage-daemon now give access to more or less the same operations
> > > in block drivers as running a system emulator.
> > > 
> > > In order to address this, introduce a new configure option that enforces
> > > the driver whitelist in all binaries.
> > 
> > Is it feasible that someone would want two separate lists: one for
> > qemu (which runs run efficiently) and another for tools (which ones do
> > we support at all)?  As written, your patch offers no chance to
> > distinguish between the two.
> 
> Possibly. However, supporting a second list would require a much larger
> code change than this patch, so I'd say this is a problem we should only
> solve when someone actually has it.
> 
> > Also, is now a good time to join the bandwagon on picking a more
> > descriptive name (such as 'allow-list') for this terminology?
> 
> I don't have an opinion on the time, but I do have an opinion on using a
> separate email thread for it. :-)

It isn't difficult - the word "white" adds no value in this arg
and can simply be removed entirely right now.
 
> Initially I tried to find a way not to use "whitelist" in the new option
> name, but that only made things inconsistent and confusing, and renaming
> the existing options is definitely out of scope for this patch.

Calling it --block-drv-list, would be consistent with the existing
--audio-drv-list. Fixing up the other existing block list args would
be nice, but should not stop use of the better name in this patch
right now.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

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