netdev - Generic sk_buff contract documentation ?

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>] [day] [month] [year] [list]

Message-ID: <1f09214d-0a30-4537-82ca-ebecc0c2f2bb@orange.com>
Date: Thu, 16 Jan 2025 08:51:26 +0100
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: netdev@...r.kernel.org
Subject: Generic sk_buff contract documentation ?

Hi,

Recently digging into a driver-specific issue with sk_buff->protocol, I
discovered (with surprise) that the computation of this field (which is *always*
necessary for protocol handlers to kick in) was somehow "delegated" to
individual network interface drivers. This can be seen by looking for callers of
eth_type_trans(), e.g:

- tg3: called from tg3_poll_work
- ixgbe: called from ixgbe_clean_rx_irq
- veth: called from veth_xmit (though indirectly via __dev_forward_skb)

This is a surprise as one would naively expect this ubiquitous behavior to be
triggered from generic code, depending only on the L2 header structure (but not
on the specific NIC hardware at hand). Another surprise was *not* to find any
mention of this "contract" in Documentation/*.

So, is it an unspoken tradition for NIC driver developers, to
"just know" that prior to emitting an skb from the rx path, they must fill
skb->protocol (along with who knows how many other metadata items) ?

Or, is there *somewhere* some reference documentation listing (exhaustively) the
required metadata computations that fall within a NIC driver's responsibility ?

Thanks in advance,

-Alex