Re: [PATCH RFC nf-next] netfilter: nf_tables: add math expression support

[Florian Westphal <fw@strlen.de>]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> Historically, users have requested support for increasing and decreasing
> TTL value in nftables in order to migrate from iptables.

Right.

> In addition, it takes into account the byteorder of the value
> stored in the source register, so there is no need to do a byteorder
> conversion before and after the math expression.

Why?  Any particular reason for this?

I would have expected to have ntf insert the needed byteorder
conversions.

> The math expression intends to be flexible enough in case it needs to be
> extended in the future, e.g implement bitfields operations. For this
> reason, the length of the data is indicated in bits instead of bytes.

Not so sure.  We already have nft_bitwise. Or what bitfield operations
are you considering?

You mean 'add' to a non-byte part, like e.g. as in iph->ihl?

> Payload set operations sometimes need 16 bits for checksum
> recalculation. Even it is a 8 bit operation, 16 bits are loaded in the
> source register. Handle such cases applying a bitmask when operating
> with 8 bits length.
> 
> As a last detail, nft_math prevents overflow of the field. If the value
> is already at its limit, do nothing.

Should it set NFT_BREAK?

> table mangle inet flags 0 use 1 handle 5
> inet mangle output use 1 type filter hook output prio 0 policy accept packets 0 bytes 0 flags 1
> inet mangle output 2
>   [ payload load 2b @ network header + 8 => reg 1 ]
>   [ math math 8 bits host reg 1 + 1 => 1]
>   [ payload write reg 1 => 2b @ network header + 8 csum_type 1 csum_off 10 csum_flags 0x0 ]

Thanks for including these examples.
You can drop the 'math' from the snprintf callback in libnftnl to avoid
this 'math math'.

I assume this says 'host' because its limited to 8 bits?

> +	/* For payload set if checksum needs to be adjusted 16 bits are stored
> +	 * in the source register instead of 8. Therefore, use a bitmask to
> +	 * operate with the less significant byte. */

I don't think this works.  You don't know if the add should be done
on the less significant byte order the MSB one.

(If you do... how?)

AFAICS you need to add support for a displacement
offset inside the register to support this (or I should write:
work-around-align-fetch-mangling ...)

> +static int nft_math_init(const struct nft_ctx *ctx,
> +			 const struct nft_expr *expr,
> +			 const struct nlattr * const tb[])
> +{
> +	struct nft_math *priv = nft_expr_priv(expr);
> +	int err;
> +
> +	if (tb[NFTA_MATH_SREG] == NULL ||
> +	    tb[NFTA_MATH_DREG] == NULL ||
> +	    tb[NFTA_MATH_LEN] == NULL ||
> +	    tb[NFTA_MATH_OP] == NULL ||
> +	    tb[NFTA_MATH_BYTEORDER] == NULL)
> +		return -EINVAL;

> +	priv->op = nla_get_u8(tb[NFTA_MATH_OP]);

Can you make it NLA_U32?  NLA_U8 doesn't buy anything except
limiting us to 255 supported options (i don't see a use case
for ever having so many, but if we ever have we don't need new OP32
attribute).

I wonder if we really want this as a module, it seems rather small.

I would also be open to just extending bitwise expression with this
inc/dec, both bitwise & math expr do register manipulations.