Re: [RFC PATCH] block/null: Use 'read-zeroes' mode by default

[Max Reitz]

On 09.02.21 18:01, Philippe Mathieu-Daudé wrote:
> The null-co driver is meant for (performance) testing.
> By default, read operation does nothing, the provided buffer
> is not filled with zero values and its content is unchanged.
>
> This can confuse security experts. For example, using the default
> null-co driver, buf[] is uninitialized, the blk_pread() call
> succeeds and we then access uninitialized memory:

I suppose in practice it’s going to be uninitialized guest memory most 
of the time, so it isn’t that bad, but yes.

Thanks!

>    static int guess_disk_lchs(BlockBackend *blk,
>                               int *pcylinders, int *pheads,
>                               int *psectors)
>    {
>        uint8_t buf[BDRV_SECTOR_SIZE];
>        ...
>
>        if (blk_pread(blk, 0, buf, BDRV_SECTOR_SIZE) < 0) {
>            return -1;
>        }
>        /* test msdos magic */
>        if (buf[510] != 0x55 || buf[511] != 0xaa) {
>            return -1;
>        }
>
> We could audit all the uninitialized buffers and the
> bdrv_co_preadv() handlers, but it is simpler to change the
> default of this testing driver. Performance tests will have
> to adapt and use 'null-co,read-zeroes=on'.
>
> Suggested-by: Max Reitz <mreitz@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> RFC maybe a stricter approach is required?

I think this is good.  If we do want a stricter approach, we might 
remove read-zeroes altogether (but I suppose that would require a 
deprecation period then) and add a new null-unsafe driver or something 
in its stead (that we can the conditionally compile out, or 
distributions can choose not to whitelist, or, or, or...).

If we just follow through with this patch, I don’t think we need a 
deprecation period, because this can well be considered a bug fix; and 
because I don’t know of any use for read-zeroes=false except for some 
very special performance tests.

> ---
>   block/null.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/null.c b/block/null.c
> index cc9b1d4ea72..f9658fd70ac 100644
> --- a/block/null.c
> +++ b/block/null.c
> @@ -93,7 +93,7 @@ static int null_file_open(BlockDriverState *bs, QDict 
> *options, int flags,
>           error_setg(errp, "latency-ns is invalid");
>           ret = -EINVAL;
>       }
> -    s->read_zeroes = qemu_opt_get_bool(opts, NULL_OPT_ZEROES, false);
> +    s->read_zeroes = qemu_opt_get_bool(opts, NULL_OPT_ZEROES, true);
>       qemu_opts_del(opts);
>       bs->supported_write_flags = BDRV_REQ_FUA;
>       return ret;

The documentation in qapi/block-core.json has to be changed, too.

Are there any iotests (or other tests) that don’t set read-zeroes? 
Should they continue to use read-zeroes=false?

Max