On Thu, Feb 20, 2025 at 4:45 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Feb 20, 2025 at 08:58:38AM +0100, Paolo Abeni wrote:
Hi,
On 2/15/25 7:04 AM, Akihiko Odaki wrote:
tun simply advances iov_iter when it needs to pad virtio header, which leaves the garbage in the buffer as is. This will become 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.
Should virtio starting sending packets only after feature negotiation? In other words, can the above happen without another bug somewhere else?
Not if this is connected with a guest with the standard virtio driver, no. The issue is that tun has no concept of feature negotiation, and we don't know who uses the vnet header feature, or why.
I guess the following question is mostly for Jason and Michael: could be possible (/would it make any sense) to use a virtio_net_hdr `flags` bit to explicitly signal the hash fields presence? i.e. making the actual virtio_net_hdr size 'dynamic'.
But it is dynamic - that is why we have TUNSETVNETHDRSZ.
Yes, tun currently only recognizes a subset of the whole virtio-net header.
Thanks