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.
Also, is now a good time to join the bandwagon on picking a more
descriptive name (such as 'allow-list') for this terminology?
> +++ b/block.c
> @@ -6162,6 +6162,9 @@ BlockDriverState
> *bdrv_find_backing_image(BlockDriverState *bs,
>
> void bdrv_init(void)
> {
> +#ifdef CONFIG_BDRV_WHITELIST_TOOLS
> + use_bdrv_whitelist = 1;
Pre-existing, but this variable seems like a natural candidate to be
bool instead of int.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
