All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaun Brady <brady.1345@gmail.com>
To: netfilter-devel@vger.kernel.org
Subject: Feedback on variable sized set elements
Date: Thu, 10 Jul 2025 23:30:48 -0400	[thread overview]
Message-ID: <aHCFaArfREnXjy5Y@fedora> (raw)

Hello,

This email is mostly for education purposes.

I'm sure I bit off more than I could chew, but I attempted to write a proof of
concept patch to add a new set type, inet_addr, which would allow elements of
both ipv4_addr and ipv6_addr types.

Something to the tune of:

nft add set inet filter set_inet {type inet_addr\;}
nft add element inet filter set_inet { 10.0.1.195, 10.0.1.200, 10.0.1.201, 2001:db8::8a2e:370:7334 }

Figuring most of this would be implemented in the nft userland, I started
there, and was able to successfully get a new set type that allowed v4
addresses OR v6 addresses, depending on how I defined the datasize of
inet_addr (4 bytes or 16 bytes).

When leaving inet_addr size at the required (for both v4 and v6) 16 bytes
netlink would return EINVAL when adding v4 addresses to the set. We found in
nft_value_init:

                if (len != desc->len)
                        return -EINVAL;

with len being the nlattr (the v4 address) and desc being the nft_set_desc. 4 != 16.


My questions:

1) Is this feature interesting enough to pursue (given what would have to be
done to make it work (see next question))?  The set type only makes sense in
inet tables (I think...) and even then, would roughly be syntactic sugar for
what could be done (more efficiently) with two sets of the base protocols. But
hey, nice things make nice tools?


2) (assuming #1) I believe we would have to put a condition to check the set
type versus the nlattr type, and allow a size difference on
set(inet_addr)/set_elem(ipv4_addr) (I don't know if that has any
ramifications).

I found set.ktype, but that is indicated to be unused in the kernel, and
comes from userland any way, so I don't believe it can be reliably used
to map to a set type.

Another possible approach would be to create an API to transmit valid size
types for a set type from userland. We would still need to ID the set type,
and that has the above problems of set.ktype.

Do either of these approaches make sense and secondly do either seem tenable?
Are there other obvious paths forward to deal with variable set element sizes?


Thanks!


SB

             reply	other threads:[~2025-07-11  3:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  3:30 Shaun Brady [this message]
2025-07-11 10:27 ` Feedback on variable sized set elements Florian Westphal
2025-07-12  2:43   ` Shaun Brady

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=aHCFaArfREnXjy5Y@fedora \
    --to=brady.1345@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.