diff mbox series

[nft] src: allow to map key to nfqueue number

Message ID 20241025074729.12412-1-fw@strlen.de
State Accepted
Headers show
Series [nft] src: allow to map key to nfqueue number | expand

Commit Message

Florian Westphal Oct. 25, 2024, 7:47 a.m. UTC
Allow to specify a numeric queue id as part of a map.
The parser side is easy, but the reverse direction (listing) is not.

'queue' is a statement, it doesn't have an expression.

Add a generic 'typeof_data_expr' as a placeholder, this is used only
for udata build/parse, it stores the "key" (the parser token, here
"queue") as udata in kernel and can then restore the original key.

Integer expression doesn't work for listing because it doesn't tell what
frontend token should be shown.

'string' doesn't work as a placeholder either because we must use a
16 bit length type, as thats what the kernel needs to reserve in the
map to hold the queue id.

Add a dumpfile to validate parser & output.
JSON support is missing because JSON doesn't allow any sort of typeof
use at this time.

Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1455
Signed-off-by: Florian Westphal <fw@strlen.de>
---
 include/expression.h                          |  15 ++-
 include/json.h                                |   2 +
 src/expression.c                              | 112 ++++++++++++++++++
 src/json.c                                    |   6 +
 src/parser_bison.y                            |   4 +
 tests/shell/testcases/nft-f/dumps/nfqueue.nft |  11 ++
 tests/shell/testcases/nft-f/nfqueue           |   6 +
 7 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 tests/shell/testcases/nft-f/dumps/nfqueue.nft
 create mode 100755 tests/shell/testcases/nft-f/nfqueue

Comments

Pablo Neira Ayuso Nov. 6, 2024, 1:28 p.m. UTC | #1
Hi Florian,

On Fri, Oct 25, 2024 at 09:47:25AM +0200, Florian Westphal wrote:
[...]
> @@ -447,6 +457,9 @@ extern struct expr *relational_expr_alloc(const struct location *loc, enum ops o
>  extern void relational_expr_pctx_update(struct proto_ctx *ctx,
>  					const struct expr *expr);
>  
> +extern struct expr *typeof_expr_alloc(const struct location *loc,
> +				      enum expr_typeof_key key);

I think it should be possible to follow an alternative path to achieve
this, that is, use integer_expr and attach a new internal datatype,
ie. queue_type, for this queue number.

No need for new TYPE_* in enum, that is only required by
concatenations and this datatype will not ever be used in that case.

For reference, there is also use of this alias datatypes such as
xinteger_type which is used to print integers in hexadecimal.

From userdata path it should be possible to check for this special
internal queue_datatype then encode the queue number type in the TLV.

Thanks.
Florian Westphal Nov. 6, 2024, 1:52 p.m. UTC | #2
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > @@ -447,6 +457,9 @@ extern struct expr *relational_expr_alloc(const struct location *loc, enum ops o
> >  extern void relational_expr_pctx_update(struct proto_ctx *ctx,
> >  					const struct expr *expr);
> >  
> > +extern struct expr *typeof_expr_alloc(const struct location *loc,
> > +				      enum expr_typeof_key key);
> 
> I think it should be possible to follow an alternative path to achieve
> this, that is, use integer_expr and attach a new internal datatype,
> ie. queue_type, for this queue number.
> 
> No need for new TYPE_* in enum, that is only required by
> concatenations and this datatype will not ever be used in that case.
> 
> For reference, there is also use of this alias datatypes such as
> xinteger_type which is used to print integers in hexadecimal.
> 
> From userdata path it should be possible to check for this special
> internal queue_datatype then encode the queue number type in the TLV.

I have no idea how to do any of this.  I don't even know what a "queue number
type" is.

How on earth do i flip the data type on postprocessing without any idea
what "2 octets worth of data" is?
Florian Westphal Nov. 6, 2024, 2:32 p.m. UTC | #3
Florian Westphal <fw@strlen.de> wrote:
> > From userdata path it should be possible to check for this special
> > internal queue_datatype then encode the queue number type in the TLV.
> 
> I have no idea how to do any of this.  I don't even know what a "queue number
> type" is.
> 
> How on earth do i flip the data type on postprocessing without any idea
> what "2 octets worth of data" is?

You seem to dislike EXPR_TYPE; I tried to sketch something but i would
turn EXPR_VALUE into EXPR_TYPE, including EXPR_TYPEOF_NFQUEUE_ID and
the udata build/parse functions, with the addition of a

 /* Dummy alias of integer_type for nf_queue id numbers */
 const struct datatype integer_queue_type = {

that has no actual function except to override what constant_expr_print()
ends up doing.

TL;DR I give up.
Pablo Neira Ayuso Nov. 6, 2024, 4:03 p.m. UTC | #4
Hi Florian,

On Wed, Nov 06, 2024 at 03:32:53PM +0100, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > > From userdata path it should be possible to check for this special
> > > internal queue_datatype then encode the queue number type in the TLV.
> > 
> > I have no idea how to do any of this.  I don't even know what a "queue number
> > type" is.
> > 
> > How on earth do i flip the data type on postprocessing without any idea
> > what "2 octets worth of data" is?
> 
> You seem to dislike EXPR_TYPE; I tried to sketch something but i would
> turn EXPR_VALUE into EXPR_TYPE, including EXPR_TYPEOF_NFQUEUE_ID and
> the udata build/parse functions, with the addition of a
> 
>  /* Dummy alias of integer_type for nf_queue id numbers */
>  const struct datatype integer_queue_type = {
> 
> that has no actual function except to override what constant_expr_print()
> ends up doing.

I am fine with your patch, it is perfectly fine to address this in
this way. I just proposed a different way to handle this special case.

I can take a look later today based on your patch, I think I can reuse
90% of it, it is just a subtle detail what I am referring to.
Pablo Neira Ayuso Nov. 6, 2024, 11:11 p.m. UTC | #5
On Wed, Nov 06, 2024 at 05:03:55PM +0100, Pablo Neira Ayuso wrote:
> I can take a look later today based on your patch, I think I can reuse
> 90% of it, it is just a subtle detail what I am referring to.

See attachment, not better than your proposal, just a different focus.
Pablo Neira Ayuso Nov. 6, 2024, 11:34 p.m. UTC | #6
On Thu, Nov 07, 2024 at 12:11:53AM +0100, Pablo Neira Ayuso wrote:
> On Wed, Nov 06, 2024 at 05:03:55PM +0100, Pablo Neira Ayuso wrote:
> > I can take a look later today based on your patch, I think I can reuse
> > 90% of it, it is just a subtle detail what I am referring to.
> 
> See attachment, not better than your proposal, just a different focus.

Actually, this attachment.
Florian Westphal Nov. 8, 2024, 12:08 p.m. UTC | #7
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Thu, Nov 07, 2024 at 12:11:53AM +0100, Pablo Neira Ayuso wrote:
> > On Wed, Nov 06, 2024 at 05:03:55PM +0100, Pablo Neira Ayuso wrote:
> > > I can take a look later today based on your patch, I think I can reuse
> > > 90% of it, it is just a subtle detail what I am referring to.
> > 
> > See attachment, not better than your proposal, just a different focus.
> 
> Actually, this attachment.

Just apply this.
Pablo Neira Ayuso Nov. 11, 2024, 10:38 a.m. UTC | #8
On Fri, Nov 08, 2024 at 01:08:54PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Thu, Nov 07, 2024 at 12:11:53AM +0100, Pablo Neira Ayuso wrote:
> > > On Wed, Nov 06, 2024 at 05:03:55PM +0100, Pablo Neira Ayuso wrote:
> > > > I can take a look later today based on your patch, I think I can reuse
> > > > 90% of it, it is just a subtle detail what I am referring to.
> > > 
> > > See attachment, not better than your proposal, just a different focus.
> > 
> > Actually, this attachment.
> 
> Just apply this.

Done.
diff mbox series

Patch

diff --git a/include/expression.h b/include/expression.h
index 8982110cce95..10733be7c02c 100644
--- a/include/expression.h
+++ b/include/expression.h
@@ -48,6 +48,7 @@ 
  * @EXPR_XFRM		XFRM (ipsec) expression
  * @EXPR_SET_ELEM_CATCHALL catchall element expression
  * @EXPR_FLAGCMP	flagcmp expression
+ * @EXPR_TYPEOF:	integer basetype encapsulation for udata
  */
 enum expr_types {
 	EXPR_INVALID,
@@ -80,8 +81,9 @@  enum expr_types {
 	EXPR_XFRM,
 	EXPR_SET_ELEM_CATCHALL,
 	EXPR_FLAGCMP,
+	EXPR_TYPEOF,
 
-	EXPR_MAX = EXPR_FLAGCMP
+	EXPR_MAX = EXPR_TYPEOF,
 };
 
 enum ops {
@@ -217,6 +219,10 @@  enum expr_flags {
 	EXPR_F_REMOVE		= 0x80,
 };
 
+enum expr_typeof_key {
+	EXPR_TYPEOF_NFQUEUE_ID,
+};
+
 #include <payload.h>
 #include <exthdr.h>
 #include <fib.h>
@@ -397,6 +403,10 @@  struct expr {
 			struct expr		*mask;
 			struct expr		*value;
 		} flagcmp;
+		struct {
+			/* EXPR_TYPEOF */
+			enum expr_typeof_key key;
+		} datatype;
 	};
 };
 
@@ -447,6 +457,9 @@  extern struct expr *relational_expr_alloc(const struct location *loc, enum ops o
 extern void relational_expr_pctx_update(struct proto_ctx *ctx,
 					const struct expr *expr);
 
+extern struct expr *typeof_expr_alloc(const struct location *loc,
+				      enum expr_typeof_key key);
+
 extern struct expr *verdict_expr_alloc(const struct location *loc,
 				       int verdict, struct expr *chain);
 
diff --git a/include/json.h b/include/json.h
index 39be8928e8ee..5b145cd51a0a 100644
--- a/include/json.h
+++ b/include/json.h
@@ -51,6 +51,7 @@  json_t *hash_expr_json(const struct expr *expr, struct output_ctx *octx);
 json_t *fib_expr_json(const struct expr *expr, struct output_ctx *octx);
 json_t *constant_expr_json(const struct expr *expr, struct output_ctx *octx);
 json_t *socket_expr_json(const struct expr *expr, struct output_ctx *octx);
+json_t *typeof_expr_json(const struct expr *expr, struct output_ctx *octx);
 json_t *osf_expr_json(const struct expr *expr, struct output_ctx *octx);
 json_t *xfrm_expr_json(const struct expr *expr, struct output_ctx *octx);
 
@@ -158,6 +159,7 @@  EXPR_PRINT_STUB(hash_expr)
 EXPR_PRINT_STUB(fib_expr)
 EXPR_PRINT_STUB(constant_expr)
 EXPR_PRINT_STUB(socket_expr)
+EXPR_PRINT_STUB(typeof_expr)
 EXPR_PRINT_STUB(osf_expr)
 EXPR_PRINT_STUB(xfrm_expr)
 
diff --git a/src/expression.c b/src/expression.c
index c0cb7f22eb73..d74addb35c66 100644
--- a/src/expression.c
+++ b/src/expression.c
@@ -332,6 +332,117 @@  struct expr *symbol_expr_alloc(const struct location *loc,
 	return expr;
 }
 
+#define NFTNL_UDATA_TYPEOF_KEY 0
+#define NFTNL_UDATA_TYPEOF_MAX NFTNL_UDATA_TYPEOF_KEY
+
+static int typeof_expr_build_udata(struct nftnl_udata_buf *udbuf,
+				   const struct expr *expr)
+{
+	if (!nftnl_udata_put_u32(udbuf, NFTNL_UDATA_TYPEOF_KEY, expr->datatype.key))
+		return -1;
+
+	return 0;
+}
+
+static int typeof_parse_udata(const struct nftnl_udata *attr, void *data)
+{
+	const struct nftnl_udata **ud = data;
+	uint8_t type = nftnl_udata_type(attr);
+	uint8_t len = nftnl_udata_len(attr);
+	uint32_t value;
+
+	switch (type) {
+	case NFTNL_UDATA_TYPEOF_KEY:
+		if (len != sizeof(uint32_t))
+			return -1;
+
+		value = nftnl_udata_get_u32(attr);
+		switch (value) {
+		case EXPR_TYPEOF_NFQUEUE_ID:
+			break;
+		default:
+			return -1;
+		}
+
+		break;
+	default:
+		return 0;
+	}
+
+	ud[type] = attr;
+	return 0;
+}
+
+static struct expr *typeof_expr_parse_udata(const struct nftnl_udata *attr)
+{
+	const struct nftnl_udata *ud[NFTNL_UDATA_TYPEOF_MAX + 1] = {};
+	enum expr_typeof_key key;
+	int err;
+
+	err = nftnl_udata_parse(nftnl_udata_get(attr), nftnl_udata_len(attr),
+				typeof_parse_udata, ud);
+	if (err < 0)
+		return NULL;
+
+	if (!ud[NFTNL_UDATA_TYPEOF_KEY])
+		return NULL;
+
+	key = nftnl_udata_get_u32(ud[NFTNL_UDATA_TYPEOF_KEY]);
+
+	return typeof_expr_alloc(&internal_location, key);
+}
+
+static const char * const typeof_key_str[] = {
+	[EXPR_TYPEOF_NFQUEUE_ID] = "queue",
+};
+
+static void typeof_expr_print(const struct expr *expr,
+			      struct output_ctx *octx)
+{
+	uint32_t v = expr->datatype.key;
+	const char *s = "unknown";
+
+	if (v < array_size(typeof_key_str))
+		s = typeof_key_str[v];
+
+	nft_print(octx, "%s", s);
+}
+
+static bool typeof_expr_cmp(const struct expr *e1, const struct expr *e2)
+{
+	return e1->datatype.key == e2->datatype.key;
+}
+
+const struct expr_ops typeof_expr_ops = {
+	.type		= EXPR_TYPEOF,
+	.name		= "typeof",
+	.print		= typeof_expr_print,
+	.json		= typeof_expr_json,
+	.cmp		= typeof_expr_cmp,
+	.build_udata	= typeof_expr_build_udata,
+	.parse_udata	= typeof_expr_parse_udata,
+};
+
+struct expr *typeof_expr_alloc(const struct location *loc,
+			       enum expr_typeof_key key)
+{
+	enum byteorder bo = BYTEORDER_INVALID;
+	struct expr *expr;
+	unsigned int len;
+
+	switch (key) {
+	case EXPR_TYPEOF_NFQUEUE_ID:
+		bo = BYTEORDER_HOST_ENDIAN;
+		len = 16;
+		break;
+	}
+
+	expr = expr_alloc(loc, EXPR_TYPEOF, &integer_type, bo, len);
+	expr->datatype.key = key;
+
+	return expr;
+}
+
 static void variable_expr_print(const struct expr *expr,
 				struct output_ctx *octx)
 {
@@ -1507,6 +1618,7 @@  static const struct expr_ops *__expr_ops_by_type(enum expr_types etype)
 {
 	switch (etype) {
 	case EXPR_INVALID: break;
+	case EXPR_TYPEOF: return &typeof_expr_ops;
 	case EXPR_VERDICT: return &verdict_expr_ops;
 	case EXPR_SYMBOL: return &symbol_expr_ops;
 	case EXPR_VARIABLE: return &variable_expr_ops;
diff --git a/src/json.c b/src/json.c
index b1531ff3f4c9..94fd968120a7 100644
--- a/src/json.c
+++ b/src/json.c
@@ -1020,6 +1020,12 @@  json_t *socket_expr_json(const struct expr *expr, struct output_ctx *octx)
 			 socket_templates[expr->socket.key].token);
 }
 
+json_t *typeof_expr_json(const struct expr *expr, struct output_ctx *octx)
+{
+	/* Need to add support for 'typeof' keyword in json set/map declarations first */
+	return NULL;
+}
+
 json_t *osf_expr_json(const struct expr *expr, struct output_ctx *octx)
 {
 	json_t *root;
diff --git a/src/parser_bison.y b/src/parser_bison.y
index e2936d10efe4..7fa114957e3e 100644
--- a/src/parser_bison.y
+++ b/src/parser_bison.y
@@ -2160,6 +2160,10 @@  typeof_data_expr	:	INTERVAL	typeof_expr
 			{
 				$$ = $1;
 			}
+			|	QUEUE
+			{
+				$$ = typeof_expr_alloc(&@$, EXPR_TYPEOF_NFQUEUE_ID);
+			}
 			;
 
 typeof_expr		:	primary_expr
diff --git a/tests/shell/testcases/nft-f/dumps/nfqueue.nft b/tests/shell/testcases/nft-f/dumps/nfqueue.nft
new file mode 100644
index 000000000000..7fe3ca669544
--- /dev/null
+++ b/tests/shell/testcases/nft-f/dumps/nfqueue.nft
@@ -0,0 +1,11 @@ 
+table inet t {
+	map get_queue_id {
+		typeof ip saddr . ip daddr . tcp dport : queue
+		elements = { 127.0.0.1 . 127.0.0.1 . 22 : 1,
+			     127.0.0.1 . 127.0.0.2 . 22 : 2 }
+	}
+
+	chain test {
+		queue flags bypass to ip saddr . ip daddr . tcp dport map @get_queue_id
+	}
+}
diff --git a/tests/shell/testcases/nft-f/nfqueue b/tests/shell/testcases/nft-f/nfqueue
new file mode 100755
index 000000000000..07820b7c4fdd
--- /dev/null
+++ b/tests/shell/testcases/nft-f/nfqueue
@@ -0,0 +1,6 @@ 
+#!/bin/bash
+
+set -e
+dumpfile=$(dirname $0)/dumps/$(basename $0).nft
+
+$NFT -f "$dumpfile"