[Top][All Lists]

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

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

From: Max Reitz
Subject: Re: [RFC PATCH] block/null: Use 'read-zeroes' mode by default
Date: Tue, 9 Feb 2021 18:09:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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.


   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);
      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?


reply via email to

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