Re: npf: nbuf_ensure_contig and large options

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Maxime Villard <max%m00nbsd.net@localhost> wrote:
> For the record, an issue I spotted some time ago; nbuf_ensure_contig calls
> m_ensure_contig with the first mbuf of the chain, but m_ensure_contig has
> a maximum 'len' argument of MHLEN, which is below the allowed option
> offset for IPv6. So if you send a big IPv6 packet, and if an option
> happens to be split across two mbufs, NPF fails to parse the packet.
> 
> There probably aren't many reasons for an IPv6 packet to have an option
> located this far, but that's theoretically possible, and more importantly,
> correct specwise.
> 
> NPF needs to be able to do an ensure_contig on secondary mbufs, without
> moving everything into the first one. Not sure how to achieve this, I will
> probably just file a PR.

I do not see that as an NPF problem.  It expects the network stack to
support certain operations and, in this case, it is a limitation of the
mbuf interface and m_ensure_contig().  As long as nbuf_ensure_contig()
failures are handled correctly -- NPF's job is done.  NPF could grow
support for operations on data spanning on multiple mbufs, but that is
slow and adds complexity.  On the other hand, we could use it only for
these special cases.

The mbuf(9) API and the underlying structuring could be improved (it is
really dated by now).  While mbufs of an arbitrary size can already be
allocated, it is very much desirable to have a fixed-size pool cache of
them (MLEN = 512 is also sensitive to performance).

I would argue that it is not worth investing a lot into this problem of
handling an edge case unless weird IPv6 option offsets become a reality.

-- 
Mindaugas