On Thu, Jan 15, 2026 at 01:46:59PM -0500, Dave Voutila wrote:
> Jan Klemkow <j.klemkow@wemelug.de> writes:
> 
> > On Wed, Jan 14, 2026 at 05:27:07PM -0500, Dave Voutila wrote:
> >> Jan Klemkow <j.klemkow@wemelug.de> writes:
> >>
> >> > On Wed, Jan 14, 2026 at 02:21:18PM -0500, Dave Voutila wrote:
> >> >> Jan Klemkow <jan@openbsd.org> writes:
> >> >>
> >> >> > On Sat, May 24, 2025 at 06:14:38AM +0000, Klemens Nanni wrote:
> >> >> >> 24.05.2025 06:33, Jan Klemkow ??????????:
> >> >> >> Still breaks:
> >> >> >>
> >> >> >> May 24 09:12:25 atar vmd[44493]: vionet_tx: bad source address 22:8d:47:b5:88:f6
> >> >> >> May 24 09:12:56 atar last message repeated 25 time
> >> >> >>
> >> >> >> Linux VM is completely offline.
> >> >> >
> >> >> > There was a bug in the csum_start and csum_offset calculation which is fixed in
> >> >> > the following diff.  I tested it successfully with Debian/Linux and OpenBSD
> >> >> > guests.
> >> >> >
> >> >> > This diff introduces optional checksum offloading for VMM guests.
> >> >> >
> >> >> > Tests are welcome.
> >> >> >
> >> >> > ok?
> >> >> >
> >> >>
> >> >> Questions in line about pledge changes.
> >> >>
> >> >> Other question is broader: why the need for memory copying with this
> >> >> offload feature?
> >> >
> >> >> I don't know how this offload works,
> >> >
> >> > When packets are just transmitted between host and guests, no one is
> >> > calculating the checksum at all.  Thus, we save two checksum calculations per
> >> > packet.  One on the sender side and another on the receiver side.  Just in case
> >> > of a transmit out of the machine via physical network, it needs to be
> >> > calculated.
> >> >

it occurred to me that whether the checksum actually is valid or not
when VIRTIO_NET_F_GUEST_CSUM is set leaks information about the network
topology. if VIRTIO_NET_F_GUEST_CSUM is set but the actual checksum
is bad, the guest can assume that the other end of the connection
is inside the machine running the hypervisor. if VIRTIO_NET_F_GUEST_CSUM
is set and the checksum is good, then it can assume the packet came from
outside the host.

the spec below mitigates against this because it basically requires the
hypervisor to scrub the checksum in the packets.

> So in reviewing the virtio spec I'm quite confused where checksumming is
> occuring with this proposed change.
> 
> From Virtio 1.2, 5.1.6.4.1 Device Requirements: Processing of Incoming
> Packets:
> 
>   If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the device
>   MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags, if so:
> 
>   1. the device MUST validate the packet checksum at offset csum_offset
>      from csum_start as well as all preceding offsets;

i read this as "the packet must be known to be good" before you can
set VIRTIO_NET_F_GUEST_CSUM. this means that it has to have come
off a physical interface with a CSUM_IN_OK flag set, or the stack/pf
has checked it and set CSUM_IN_OK, or it was created inside the
machine.

>   2. the device MUST set the packet checksum stored in the receive buffer
>      to the TCP/UDP pseudo header;

this makes locally generated and packets off the wire look the same to
the guest. you're unconditionally overwriting the packet checksum field
if VIRTIO_NET_F_GUEST_CSUM gets set.

>   3. the device MUST set csum_start and csum_offset such that
>      calculating a ones' complement checksum from csum_start up until
>      the end of the packet and storing the result at offset csum_offset
>      from csum_start will result in a fully checksummed packet;
> 
> This reads like vionet needs to be computing checksums in some cases
> when we set VIRTIO_NET_HDR_F_NEEDS_CSUM...which appears to happen in
> thdr2vhdr() on the rx side.
> 
> (It also blindly sets that flag and assumes the guest/driver actually
> negotiated VIRTIO_NET_F_GUEST_CSUM, which is not a safe assumption.)