netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Haller <thaller@redhat.com>
To: NetFilter <netfilter-devel@vger.kernel.org>
Cc: Thomas Haller <thaller@redhat.com>
Subject: [PATCH nft 8/9] datatype: use __attribute__((packed)) instead of enum bitfields
Date: Wed, 20 Sep 2023 16:26:09 +0200	[thread overview]
Message-ID: <20230920142958.566615-9-thaller@redhat.com> (raw)
In-Reply-To: <20230920142958.566615-1-thaller@redhat.com>

At some places we use bitfields of those enums, to save space inside the
structure. We can achieve that in a better way, by using GCC's
__attribute__((packed)) on the enum type.

It's better because a :8 bitfield makes the assumption that all enum
values (valid or invalid) fit into that field. With packed enums, we
don't need that assumption as the field can hold all possible numbers
that the enum type can hold. This reduces the places we need to worry
about truncating a value to casts between other types and the enum.
Those places already require us to be careful.

On the other hand, previously casting an int (or uint32_t) likely didn't
cause a truncation as the underlying type was large enough. So we could
check for invalid enum values after the cast. We might do that at
places. For example, we do

	key  = nftnl_expr_get_u32(nle, NFTNL_EXPR_META_KEY);
	expr = meta_expr_alloc(loc, key);

where we cast from an uint32_t to an enum without checking. Note that
`enum nft_meta_keys` is not packed by this patch. But this is an example
how things could be wrong. But the bug already exits before: don't make
assumption about the underlying enum type and take care of truncation
during casts.

This makes the change potentially dangerous, and it's hard to be sure
that it doesn't uncover bugs (due tow rong assumptions about enum types).

Note that we were already using the GCC-ism __attribute__((packed))
previously, however on a struct and not on an enum. Anyway. It seems
unlikely that we support any other compilers than GCC/Clang. Those both
support this attribute.  We should not worry about portability towards
hypothetical compilers (the C standard), unless there is a real compiler
that we can use and test and shows a problem with this. Especially when
we support both GCC and Clang, which themselves are ubiquitous and
accessible to all users (as they also need to build the kernel in the
first place).

Signed-off-by: Thomas Haller <thaller@redhat.com>
---
 include/datatype.h   |  1 +
 include/expression.h |  8 +++++---
 include/proto.h      | 11 +++++++----
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/include/datatype.h b/include/datatype.h
index 202935bd322f..c8b3b77ad0c0 100644
--- a/include/datatype.h
+++ b/include/datatype.h
@@ -112,6 +112,7 @@ enum datatypes {
  * @BYTEORDER_HOST_ENDIAN:	host endian
  * @BYTEORDER_BIG_ENDIAN:	big endian
  */
+__attribute__((packed))
 enum byteorder {
 	BYTEORDER_INVALID,
 	BYTEORDER_HOST_ENDIAN,
diff --git a/include/expression.h b/include/expression.h
index aede223db741..11a1dbf00b8c 100644
--- a/include/expression.h
+++ b/include/expression.h
@@ -45,6 +45,7 @@
  * @EXPR_SET_ELEM_CATCHALL catchall element expression
  * @EXPR_FLAGCMP	flagcmp expression
  */
+__attribute__((packed))
 enum expr_types {
 	EXPR_INVALID,
 	EXPR_VERDICT,
@@ -80,6 +81,7 @@ enum expr_types {
 	EXPR_MAX = EXPR_FLAGCMP
 };
 
+__attribute__((packed))
 enum ops {
 	OP_INVALID,
 	OP_IMPLICIT,
@@ -247,9 +249,9 @@ struct expr {
 	unsigned int		flags;
 
 	const struct datatype	*dtype;
-	enum byteorder		byteorder:8;
-	enum expr_types		etype:8;
-	enum ops		op:8;
+	enum byteorder		byteorder;
+	enum expr_types		etype;
+	enum ops		op;
 	unsigned int		len;
 	struct cmd		*cmd;
 
diff --git a/include/proto.h b/include/proto.h
index 3a20ff8c4071..3756a4ab79a4 100644
--- a/include/proto.h
+++ b/include/proto.h
@@ -13,6 +13,7 @@
  * @PROTO_BASE_NETWORK_HDR:	network layer header
  * @PROTO_BASE_TRANSPORT_HDR:	transport layer header
  */
+__attribute__((packed))
 enum proto_bases {
 	PROTO_BASE_INVALID,
 	PROTO_BASE_LL_HDR,
@@ -26,6 +27,7 @@ enum proto_bases {
 extern const char *proto_base_names[];
 extern const char *proto_base_tokens[];
 
+__attribute__((packed))
 enum icmp_hdr_field_type {
 	PROTO_ICMP_ANY = 0,
 	PROTO_ICMP_ECHO,	/* echo and reply */
@@ -52,9 +54,9 @@ struct proto_hdr_template {
 	const struct datatype		*dtype;
 	uint16_t			offset;
 	uint16_t			len;
-	enum byteorder			byteorder:8;
+	enum byteorder			byteorder;
 	enum nft_meta_keys		meta_key:8;
-	enum icmp_hdr_field_type	icmp_dep:8;
+	enum icmp_hdr_field_type	icmp_dep;
 };
 
 #define PROTO_HDR_TEMPLATE(__token, __dtype,  __byteorder, __offset, __len)\
@@ -77,6 +79,7 @@ struct proto_hdr_template {
 #define PROTO_UPPER_MAX		16
 #define PROTO_HDRS_MAX		20
 
+__attribute__((packed))
 enum proto_desc_id {
 	PROTO_DESC_UNKNOWN	= 0,
 	PROTO_DESC_AH,
@@ -119,8 +122,8 @@ enum proto_desc_id {
  */
 struct proto_desc {
 	const char			*name;
-	enum proto_desc_id		id:8;
-	enum proto_bases		base:8;
+	enum proto_desc_id		id;
+	enum proto_bases		base;
 	enum nft_payload_csum_types	checksum_type:8;
 	uint16_t			checksum_key;
 	uint16_t			protocol_key;
-- 
2.41.0


  parent reply	other threads:[~2023-09-20 14:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-20 14:26 [PATCH nft 0/9] various cleanups related to enums and struct datatype Thomas Haller
2023-09-20 14:26 ` [PATCH nft 1/9] src: fix indentation/whitespace Thomas Haller
2023-09-20 16:03   ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 2/9] include: fix missing definitions in <cache.h>/<headers.h> Thomas Haller
2023-09-20 14:26 ` [PATCH nft 3/9] datatype: drop flags field from datatype Thomas Haller
2023-09-20 18:10   ` Pablo Neira Ayuso
2023-09-20 19:23     ` Thomas Haller
2023-09-21 14:23       ` Pablo Neira Ayuso
2023-09-22  8:51         ` Thomas Haller
2023-09-22 11:18           ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 4/9] datatype: use "enum byteorder" instead of int in set_datatype_alloc() Thomas Haller
2023-09-20 16:27   ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 5/9] payload: use enum icmp_hdr_field_type in payload_may_dependency_kill_icmp() Thomas Haller
2023-09-20 16:32   ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 6/9] netlink: handle invalid etype in set_make_key() Thomas Haller
2023-09-20 16:22   ` Pablo Neira Ayuso
2023-09-20 16:24   ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 7/9] expression: cleanup expr_ops_by_type() and handle u32 input Thomas Haller
2023-09-20 18:13   ` Pablo Neira Ayuso
2023-09-20 19:28     ` Thomas Haller
2023-09-21 14:19       ` Pablo Neira Ayuso
2023-09-22  8:54         ` Thomas Haller
2023-09-22  9:56           ` Pablo Neira Ayuso
2023-09-25  8:44           ` Pablo Neira Ayuso
2023-09-20 14:26 ` Thomas Haller [this message]
2023-09-20 16:02   ` [PATCH nft 8/9] datatype: use __attribute__((packed)) instead of enum bitfields Pablo Neira Ayuso
2023-09-20 17:48     ` Thomas Haller
2023-09-20 18:07       ` Pablo Neira Ayuso
2023-09-20 16:46   ` Pablo Neira Ayuso
2023-09-20 14:26 ` [PATCH nft 9/9] proto: add missing proto_definitions for PROTO_DESC_GENEVE Thomas Haller
2023-09-20 16:14   ` Pablo Neira Ayuso

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=20230920142958.566615-9-thaller@redhat.com \
    --to=thaller@redhat.com \
    --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).