On 2021-02-23 17:01, Max Reitz wrote: > On 23.02.21 10:21, Fam Zheng wrote: > > On 2021-02-22 18:55, Philippe Mathieu-Daudé wrote: > > > On 2/22/21 6:35 PM, Fam Zheng wrote: > > > > On 2021-02-19 15:09, Philippe Mathieu-Daudé wrote: > > > > > On 2/19/21 12:07 PM, Max Reitz wrote: > > > > > > On 13.02.21 22:54, Fam Zheng wrote: > > > > > > > On 2021-02-11 15:26, Philippe Mathieu-Daudé wrote: > > > > > > > > The null-co driver doesn't zeroize buffer in its default config, > > > > > > > > because it is designed for testing and tests want to run fast. > > > > > > > > However this confuses security researchers (access to uninit > > > > > > > > buffers). > > > > > > > > > > > > > > I'm a little surprised. > > > > > > > > > > > > > > Is changing default the only way to fix this? I'm not opposed to > > > > > > > changing the default but I'm not convinced this is the easiest > > > > > > > way. > > > > > > > block/nvme.c also doesn't touch the memory, but defers to the > > > > > > > device > > > > > > > DMA, why doesn't that confuse the security checker? > > > > > > > > > > Generally speaking, there is a balance between security and > > > > > performance. > > > > > We try to provide both, but when we can't, my understanding is > > > > > security > > > > > is more important. > > > > > > > > Why is hiding the code path behind a non-default more secure? What is > > > > not secure now? > > > > > > Se we are back to the problem of having default values. > > > > > > I'd like to remove the default and have the option explicit, > > > but qemu_opt_get_bool() expects a 'default' value. > > > > > > Should we rename qemu_opt_get_bool() -> qemu_opt_get_bool_with_default() > > > and add a simpler qemu_opt_get_bool()? > > > > My point is I still don't get the full context of the problem this > > series is trying to solve. If the problem is tools are confused, I would > > like to understand why. What is the thing that matters here, exactly? > > My personal opinion is that it isn’t even about tools, it’s just about the > fact that operating on uninitialized data is something that should generally > be avoided. For the null drivers, there is a reason to allow it > (performance testing), but that should be a special case, not the default.
How do we define uninitialized data? Are buffers passed to a successful read (2) syscall initialized? We cannot know, because it's up to the fs/driver/storage. It's the same to bdrv_pread(). In fact block/null.c doesn't operate on uninitialized data, we should really fix guess_disk_lchs() and similar. > > > But there's always been nullblk.ko in kernel that doesn't lie in the > > name. If we change the default we are not very honest any more about > > what the driver actually does. > > Then we’re already lying, because if we model it after /dev/null, we should > probably return -EIO on every read. nullblk.ko is not /dev/null, it's /dev/nullb*: https://www.kernel.org/doc/Documentation/block/null_blk.txt Fam
