On Thu 09-01-25 18:36:52, Akihiko Odaki wrote:

On 2025/01/09 16:43, Michael S. Tsirkin wrote:

quoted

On Thu, Jan 09, 2025 at 04:41:50PM +0900, Akihiko Odaki wrote:

quoted

On 2025/01/09 16:31, Michael S. Tsirkin wrote:

quoted

On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:

quoted

tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the hash reporting
feature; even if the feature is enabled, the packet may lack a hash
value and may contain a hole in the virtio header because the packet
arrived before the feature gets enabled or does not contain the
header fields to be hashed. If the hole is not filled with zero, it is
impossible to tell if the packet lacks a hash value.

In theory, a user of tun can fill the buffer with zero before calling
read() to avoid such a problem, but leaving the garbage in the buffer is
awkward anyway so fill the buffer in tun.

Signed-off-by: Akihiko Odaki <redacted>

But if the user did it, you have just overwritten his value,
did you not?

Yes. but that means the user expects some part of buffer is not filled after
read() or recvmsg(). I'm a bit worried that not filling the buffer may break
assumptions others (especially the filesystem and socket infrastructures in
the kernel) may have.

If we are really confident that it will not cause problems, this behavior
can be opt-in based on a flag or we can just write some documentation
warning userspace programmers to initialize the buffer.

It's been like this for years, I'd say we wait until we know there's a problem?

Perhaps we can just leave it as is. Let me ask filesystem and networking
people:

Is it OK to leave some part of buffer uninitialized with read_iter() or
recvmsg()?

I think that leaving part of the IO buffer within returned IO length
uninitialized is a very bad practice and I'm not aware of any place in
filesystem area that would do that. It makes life unnecessarily harder
for userspace and also it is invitation for subtle information leaks
(depending on who allocates the buffer and who then gets to read the
results). So I think the patch makes sense.

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR