netdev - Re: [PATCH net-next v15 14/15] net: homa: create homa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXJAmzgw3FCgXaKHQr4fFJw-ETsuD_uyZC54AHV76BGH280vA@mail.gmail.com>
Date: Tue, 2 Sep 2025 16:15:16 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, horms@...nel.org, 
	kuba@...nel.org
Subject: Re: [PATCH net-next v15 14/15] net: homa: create homa_plumbing.c

On Tue, Sep 2, 2025 at 1:12 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 9/2/25 12:53 AM, John Ousterhout wrote:
> > On Tue, Aug 26, 2025 at 9:17 AM Paolo Abeni <pabeni@...hat.com> wrote:
> >>> +             header_offset = skb_transport_header(skb) - skb->data;
> >>> +             if (header_offset)
> >>> +                     __skb_pull(skb, header_offset);
> >>> +
> >>> +             /* Reject packets that are too short or have bogus types. */
> >>> +             h = (struct homa_common_hdr *)skb->data;
> >>> +             if (unlikely(skb->len < sizeof(struct homa_common_hdr) ||
> >>> +                          h->type < DATA || h->type > MAX_OP ||
> >>> +                          skb->len < header_lengths[h->type - DATA]))
> >>> +                     goto discard;
> >>> +
> >>> +             /* Process the packet now if it is a control packet or
> >>> +              * if it contains an entire short message.
> >>> +              */
> >>> +             if (h->type != DATA || ntohl(((struct homa_data_hdr *)h)
> >>> +                             ->message_length) < 1400) {
> >>
> >> I could not fined where `message_length` is validated. AFAICS
> >> data_hdr->message_length could be > skb->len.
> >>
> >> Also I don't see how the condition checked above ensures that the pkt
> >> contains the whole message.
> >
> > Long messages consist of multiple packets, so it is fine if
> > data_hdr->message_length > skb->len. That said, Homa does not fragment
> > a message into multiple packets unless necessary, so if the condition
> > above is met, then the message is contained in a single packet (if for
> > some reason a sender fragments a short message, that won't cause
> > problems).
>
> Let me rephrase: why 1400? is that MRU dependent, or just an arbitrary
> threshold? What if the NIC can receive 8K frames (or max 1024 bytes long
> one)? What if the stack adds a long encapsulation?
>
> What if an evil/bugged peer set message_length to a random value (larger
> than the amount of bytes actually sent or smaller than that)?

1400 is an arbitrary threshold. This has no impact on functionality or
correctness; it is simply used to reorder the packets in a batch so
that shorter messages get processed first. If the NIC can receive 8K
frames it won't change this threshold; only frames shorter than 1400
will get the scheduling boost. If a message shorter than 1400 bytes
arrives in multiple packets, all of the packets will get the boost.

A sender could cheat the mechanism by declaring the message length to
less than 1400 bytes when the message is really longer than that. This
would cause the message's packets to get priority for SoftIRQ
processing, but all of the extra data in the message beyond the stated
length would be discarded, so I'm not sure how the sender would
benefit from this.

-John-