Re: RFC: a checked mbuf accessor for -fbounds-safety

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Mon, 21 Sep 2026 14:48:38 UTC
hi! a couple of questions!

On Tue, 15 Sept 2026 at 16:30, Abhijeet Sharma <abhijeetsharma2002@gmail.com>
wrote:

> Hi,
>
> I am adopting Clang's -fbounds-safety in the kernel TCP/IP stack under a
> FreeBSD Foundation project, with rpaulo@ as technical monitor.  The
> groundwork is in review as D58983 through D58987(M2), four of five
> accepted,
> adding the annotation vocabulary to sys/cdefs.h, a per-file opt-in to
> kern.mk that is empty by default, and a soft-trap runtime that counts a
> failed check and lets the kernel continue instead of panicking.  The access
> itself still happens, so bring-up gets a count and a backtrace rather than
> a
> mitigation.  Hard mode is the switch for that later.  Toolchain recipe at
> https://wiki.freebsd.org/BoundsSafety.
>
> None of that touches packet data, which is the next step, so I would like
> to agree the interface before sending the patch.
>
> mtod() is a cast of m_data, and no sibling field carries the storage bound.
> m_len is a sibling, so __sized_by(m_len) is expressible, but it describes
> the valid data rather than the storage.  The storage bound lives in
> M_START() and M_SIZE(), which are conditionals over m_flags, so no
> attribute can state it.  M2 marked m_data __unsafe_indexable, so all
> 2231 mtod() call sites produce unchecked pointers, and annotating netinet
> on top of that would check the parameters while leaving every packet read
> unchecked.  xnu hit the same wall and rebuilt the pointer through an
> accessor that reattaches the storage bound.  This follows that shape.
>

What's the story with xnu? Did Apple already explore this space?
Is the code viewable somewhere?

[snip code]

I have other questions about it too - mostly centred around whether
part of this effort could be better served by figuring out what some
better mbuf APIs would be (eg m_copydata but for copying
mbuf regions into mbufs, complete with bounds checking AND
returning errors) and better mbuf usage patterns versus the
traditional mtod. (eg, we /do/ have an mtodo() macro which does
take the mbuf + offset, but we don't have one that takes an
offset + length AND returns a NULL if it can't satisfy this with the
mbuf in question.)



-adrian