All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH] block: Add option to use driver whitelist even in tools
Date: Mon, 12 Jul 2021 16:44:08 +0100	[thread overview]
Message-ID: <YOxjSKB4rqdfyZx9@redhat.com> (raw)
In-Reply-To: <YOv61o84+UTgq7PX@redhat.com>

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



      parent reply	other threads:[~2021-07-12 15:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-09 16:41 [PATCH] block: Add option to use driver whitelist even in tools Kevin Wolf
2021-07-09 17:45 ` Eric Blake
2021-07-12  8:18   ` Kevin Wolf
2021-07-12 15:28     ` Eric Blake
2021-07-12 15:44     ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YOxjSKB4rqdfyZx9@redhat.com \
    --to=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.