Re: [libnftnl RFC] data_reg: Improve data reg value printing

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Phil,

On Tue, Sep 16, 2025 at 12:16:42AM +0200, Phil Sutter wrote:
> Hi Pablo,
> 
> On Mon, Sep 15, 2025 at 11:19:27PM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Sep 11, 2025 at 04:11:45PM +0200, Phil Sutter wrote:
> > > The old code printing each field with data as u32 value is problematic
> > > in two ways:
> > > 
> > > A) Field values are printed in host byte order which may not be correct
> > >    and output for identical data will divert between machines of
> > >    different Endianness.
> > > 
> > > B) The actual data length is not clearly readable from given output.
> > > 
> > > This patch won't entirely fix for (A) given that data may be in host
> > > byte order but it solves for the common case of matching against packet
> > > data.
> > > 
> > > Fixing for (B) is crucial to see what's happening beneath the bonnet.
> > > The new output will show exactly what is used e.g. by a cmp expression.
> > 
> > Could you fix this from libnftables? ie. add print functions that have
> > access to the byteorder, so print can do accordingly.
> 
> You mean replacing nftnl_expr_fprintf() and all per-expr callbacks
> entirely? I guess this exposes lots of libnftnl internals to
> libnftables.
>
> IIRC, the last approach from 2020 was to communicate LHS byteorder to
> RHS in libnftnl internally and in addition to that annotate sets with
> element byteorder info (which is not entirely trivial due to
> concatenations of data with varying byteorder.
>
> I don't get the code in my old branches anymore, though. Maybe if I read
> up on our past mails. Or maybe we just retry from scratch with a fresh
> mind. :)

Maybe this approach?

For immediates, a new libnftnl function could help us deal with this:

-                nftnl_expr_set(nle, NFTNL_EXPR_CMP_DATA, nld2.value, nld2.len);
+                nftnl_expr_set_imm(nle, NFTNL_EXPR_CMP_DATA, nld2.value, nld2.len, nld2.byteorder);

Then, for set elements, add a new field here:

struct nft_data_linearize {
        uint32_t        len;
        uint32_t        value[NFT_REG32_COUNT];
+       uint32_t        byteorder[NFT_REG32_COUNT];

where byteorder stores a bitmask that specifies byteorder, 0 can be
network endian and 1 host endian, the length of the bitmask length
tells us the size of this field.

Then, add nftnl_set_elem_set_imm() that takes nld.byteorder.

From libnftnl, use this bitmask from _snprintf to swap bits
accordingly.

union nftnl_data_reg would need to be modified to store this
byteorder[] array including the bitmask. This will not increase memory
consumption because only one intermediate libnftnl object is used to
generate the netlink bytecode blob at a time.

This should not be too hard to make it work for userspace -> kernel.

Would this be good enough to make tests/py happy?