qemu-block
[Top][All Lists]
Advanced

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

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 0/3] block: Introduce the 'zeroes-co' driver to help security reports
Date: Wed, 10 Mar 2021 13:37:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 3/10/21 1:32 PM, Fam Zheng wrote:
> On Wed, 10 Mar 2021 at 11:44, Philippe Mathieu-Daudé <philmd@redhat.com
> <mailto:philmd@redhat.com>> 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
>     <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.
> 
>     The 2nd patch is RFC because I won't spend time converting the
>     tests until the first patch is discussed, as I already spent enough
>     time doing that in the previous mentioned series.
> 
>     Regards,
> 
>     Phil.
> 
>     Philippe Mathieu-Daudé (3):
>       block: Introduce the 'zeroes-co' driver
>       tests/test-blockjob: Use zeroes-co instead of null-co,read-zeroes=on
>       docs/secure-coding-practices: Describe null-co/zeroes-co block drivers
> 
>      docs/devel/secure-coding-practices.rst |   7 +
>      block/zeroes.c                         | 306 +++++++++++++++++++++++++
> 
> Why not add another BlockDriver struct to block/null.c and set the
> read_zeroes field in the .bdrv_file_open callback? It would make the
> patch much simpler.

This is the first patch I wrote but then realized you are listed as
null-co maintainer, so you might be uninterested in having this new
driver in the same file. And declaring the prototypes public to
reuse them seemed overkill.

Anyway I'll try to find a simpler outcome by simply improving
documentation.




reply via email to

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