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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 3/10/21 12:55 PM, Daniel P. Berrangé wrote:
> 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]

Yes I totally agree with Max, but Fam is the maintainer.

I'll keep looking for alternatives. Maybe simply documentation.

Thanks,

Phil.