Re: [PATCH 0/3] block: Introduce the 'zeroes-co' driver to help security reports

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Mar 10, 2021 at 12:43:11PM +0100, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> This is an alternative approach to changing null-co driver
> default 'read-zeroes' option to true:
> https://www.mail-archive.com/qemu-block@nongnu.org/msg80873.html
> 
> Instead we introduce yet another block driver with an explicit
> name: 'zeroes-co'. We then clarify in secure-coding-practices.rst
> that security reports have to be sent using this new driver.

IMHO introducing a new block driver, when this can be solved by
simply adding a property to the existing driver, just feels mad
Your previous series made much more sense, and despite the long
thread, I didn't see anyone suggest a real world blocker with
making it read zeros by default.

I think Max's last mail sums it up pretty well

  https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg07173.html

[quote]
In cases where we have a test that just wants a simple block node that
doesn’t use disk space, the memset() can’t be noticeable. But it’s just
a test, so do we even need the memset()? Strictly speaking, perhaps not,
but if someone is to run it via Valgrind or something, they may get
false positives, so just doing the memset() is the right thing to do.

For performance tests, it must be possible to set read-zeroes=off,
because even though “that memset() isn’t noticeable in a functional
test”, in a hard-core performance test, it will be.

So we need a switch. It should default to memset(), because (1) making
tools like Valgrind happy seems like a reasonable objective to me, and
(2) in the majority of cases, the memset() cannot have a noticeable
impact.
[/quote]


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