From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jeremy Sowden <jeremy@azazel.net>
Cc: Netfilter Devel <netfilter-devel@vger.kernel.org>,
Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Subject: Re: [nft PATCH v4 08/32] netlink: send bit-length of bitwise binops to kernel
Date: Mon, 23 May 2022 19:03:42 +0200 [thread overview]
Message-ID: <You+bsAw2mbUuE6S@salvia> (raw)
In-Reply-To: <20220404121410.188509-9-jeremy@azazel.net>
Hi,
I'm sorry for taking time to get back to this, I have questions.
On Mon, Apr 04, 2022 at 01:13:46PM +0100, Jeremy Sowden wrote:
> Some bitwise operations are generated when munging paylod expressions.
> During delinearization, we attempt to eliminate these operations.
> However, this is done before deducing the byte-order or the correct
> length in bits of the operands, which means that we don't always handle
> multi-byte host-endian operations correctly. Therefore, pass the
> bit-length of these expressions to the kernel in order to have it
> available during delinearization.
>
> Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
> ---
> src/netlink_delinearize.c | 14 ++++++++++++--
> src/netlink_linearize.c | 2 ++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/netlink_delinearize.c b/src/netlink_delinearize.c
> index a1b00dee209a..733977bc526d 100644
> --- a/src/netlink_delinearize.c
> +++ b/src/netlink_delinearize.c
> @@ -451,20 +451,28 @@ static struct expr *netlink_parse_bitwise_bool(struct netlink_parse_ctx *ctx,
> const struct nftnl_expr *nle,
> enum nft_registers sreg,
> struct expr *left)
> -
> {
> struct nft_data_delinearize nld;
> struct expr *expr, *mask, *xor, *or;
> + unsigned int nbits;
> mpz_t m, x, o;
>
> expr = left;
>
> + nbits = nftnl_expr_get_u32(nle, NFTNL_EXPR_BITWISE_NBITS);
> + if (nbits > 0)
> + expr->len = nbits;
So NFTNL_EXPR_BITWISE_NBITS is signalling that this is an implicit
bitwise that has been generated to operate with a payload header bitfield?
Could you provide an example expression tree to show how this
simplifies delinearization?
> +
> nld.value = nftnl_expr_get(nle, NFTNL_EXPR_BITWISE_MASK, &nld.len);
> mask = netlink_alloc_value(loc, &nld);
> + if (nbits > 0)
> + mpz_switch_byteorder(mask->value, div_round_up(nbits, BITS_PER_BYTE));
What is the byteorder expected for the mask before this switch
operation?
> mpz_init_set(m, mask->value);
>
> nld.value = nftnl_expr_get(nle, NFTNL_EXPR_BITWISE_XOR, &nld.len);
> - xor = netlink_alloc_value(loc, &nld);
> + xor = netlink_alloc_value(loc, &nld);
> + if (nbits > 0)
> + mpz_switch_byteorder(xor->value, div_round_up(nbits, BITS_PER_BYTE));
> mpz_init_set(x, xor->value);
>
> mpz_init_set_ui(o, 0);
> @@ -500,6 +508,8 @@ static struct expr *netlink_parse_bitwise_bool(struct netlink_parse_ctx *ctx,
>
> or = netlink_alloc_value(loc, &nld);
> mpz_set(or->value, o);
> + if (nbits > 0)
> + mpz_switch_byteorder(or->value, div_round_up(nbits, BITS_PER_BYTE));
> expr = binop_expr_alloc(loc, OP_OR, expr, or);
> expr->len = left->len;
> }
> diff --git a/src/netlink_linearize.c b/src/netlink_linearize.c
> index c8bbcb7452b0..4793f3853bee 100644
> --- a/src/netlink_linearize.c
> +++ b/src/netlink_linearize.c
> @@ -677,6 +677,8 @@ static void netlink_gen_bitwise(struct netlink_linearize_ctx *ctx,
> netlink_put_register(nle, NFTNL_EXPR_BITWISE_DREG, dreg);
> nftnl_expr_set_u32(nle, NFTNL_EXPR_BITWISE_OP, NFT_BITWISE_BOOL);
> nftnl_expr_set_u32(nle, NFTNL_EXPR_BITWISE_LEN, len);
> + if (expr->byteorder == BYTEORDER_HOST_ENDIAN)
> + nftnl_expr_set_u32(nle, NFTNL_EXPR_BITWISE_NBITS, expr->len);
Why is this only required for host endian expressions?
> netlink_gen_raw_data(mask, expr->byteorder, len, &nld);
> nftnl_expr_set(nle, NFTNL_EXPR_BITWISE_MASK, nld.value, nld.len);
> --
> 2.35.1
>
next prev parent reply other threads:[~2022-05-23 17:03 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 12:13 [nft PATCH v4 00/32] Extend values assignable to packet marks and payload fields Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 01/32] examples: add .gitignore file Jeremy Sowden
2022-04-05 11:26 ` Florian Westphal
2022-04-04 12:13 ` [nft PATCH v4 02/32] include: add missing `#include` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 03/32] src: move `byteorder_names` array Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 04/32] datatype: support `NULL` symbol-tables when printing constants Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 05/32] ct: support `NULL` symbol-tables when looking up labels Jeremy Sowden
2022-04-05 11:15 ` Florian Westphal
2022-04-05 15:29 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 06/32] include: update nf_tables.h Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 07/32] include: add new bitwise bit-length attribute to nf_tables.h Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 08/32] netlink: send bit-length of bitwise binops to kernel Jeremy Sowden
2022-05-23 17:03 ` Pablo Neira Ayuso [this message]
2022-11-01 18:46 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 09/32] netlink_delinearize: add postprocessing for payload binops Jeremy Sowden
2022-05-23 17:19 ` Pablo Neira Ayuso
2022-11-01 18:46 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 10/32] netlink_delinearize: correct type and byte-order of shifts Jeremy Sowden
2022-05-23 17:19 ` Pablo Neira Ayuso
2022-11-01 18:47 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 11/32] netlink_delinearize: correct length of right bitwise operand Jeremy Sowden
2022-05-23 17:22 ` Pablo Neira Ayuso
2022-11-01 18:47 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 12/32] payload: set byte-order when completing expression Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 13/32] evaluate: support shifts larger than the width of the left operand Jeremy Sowden
2022-05-23 17:42 ` Pablo Neira Ayuso
2022-11-01 18:47 ` Jeremy Sowden
2023-02-07 12:05 ` Pablo Neira Ayuso
2023-03-04 12:00 ` Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 14/32] evaluate: relax type-checking for integer arguments in mark statements Jeremy Sowden
2022-05-23 17:33 ` Pablo Neira Ayuso
2022-04-04 12:13 ` [nft PATCH v4 15/32] tests: shell: rename some test-cases Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 16/32] tests: shell: add test-cases for ct and packet mark payload expressions Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 17/32] tests: py: " Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 18/32] include: add new bitwise boolean attributes to nf_tables.h Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 19/32] evaluate: don't eval unary arguments Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 20/32] evaluate: prevent nested byte-order conversions Jeremy Sowden
2022-04-04 12:13 ` [nft PATCH v4 21/32] evaluate: don't clobber binop lengths Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 22/32] evaluate: insert byte-order conversions for expressions between 9 and 15 bits Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 23/32] evaluate: set eval context to leftmost bitwise operand Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 24/32] netlink_delinearize: fix typo Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 25/32] netlink_delinearize: refactor stmt_payload_binop_postprocess Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 26/32] netlink_delinearize: add support for processing variable payload statement arguments Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 27/32] netlink: rename bitwise operation functions Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 28/32] netlink: support (de)linearization of new bitwise boolean operations Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 29/32] parser_json: allow RHS ct, meta and payload expressions Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 30/32] evaluate: allow binop expressions with variable right-hand operands Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 31/32] tests: shell: add tests for binops with variable RHS operands Jeremy Sowden
2022-04-04 12:14 ` [nft PATCH v4 32/32] tests: py: " Jeremy Sowden
2022-04-09 8:30 ` [nft PATCH v4 00/32] Extend values assignable to packet marks and payload fields Kevin 'ldir' Darbyshire-Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=You+bsAw2mbUuE6S@salvia \
--to=pablo@netfilter.org \
--cc=jeremy@azazel.net \
--cc=ldir@darbyshire-bryant.me.uk \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).