From: Mark Montague <mark@catseye.org>
To: netfilter-devel@vger.kernel.org
Subject: questions about variable-sized data in match rules
Date: Sun, 20 Mar 2011 00:03:18 -0400 [thread overview]
Message-ID: <4D857C86.1010009@catseye.org> (raw)
I'm writing a netfilter match extension (kernel 2.6.35.11) that has
arguments of indeterminate length. There are six possible arguments,
each of which is a string with no pre-set maximum length. Typically, a
match rule would only specify one or two of these arguments, although it
is theoretically possible to have a rule with all six. Each argument
can only occur once and is typically 30-50 characters, although it is
possible to have arguments that are 100 characters or more each (there
is no pre-set maximum length). Here is an example that uses only two of
the six possible arguments:
iptables -A INPUT -m mymatch --arg1 some-long-string --arg5
another-even-longer-string -j ACCEPT
It seems to me that allocating memory via malloc() in the parse hook
function, including a pointer for each argument in the match info
structure, and using copy_from_user() in the checkentry hook function
would be bad, since the match info structure is copied to kernel space
across a netlink socket and the checkentry hook function may run after
the userspace process has terminated. Is this conclusion correct?
The best solution I have come up with so far is to have a pool for all
arguments, with indexes into the pool for each argument:
struct mymatch_mtinfo {
char pool[256]; /* strings in pool are separated by '\0' */
__u8 arg1_pool_offset; /* index into pool for argument 1 */
__u8 arg2_pool_offset;
__u8 arg3_pool_offset;
__u8 arg4_pool_offset;
__u8 arg5_pool_offset;
__u8 arg6_pool_offset;
}
This would work in all but pathological cases, since a rule will
normally only have one or two arguments each of which should be well
below 100 characters. If the total number of characters across all
arguments is more than 255, the parse hook function would throw an error
and say that although everything is be legal, together it is all more
than the netfilter extension can handle.
Can anyone think of a better solution for passing six strings with no
pre-set lengths to the kernel netfilter extension module?
Thanks in advance for any advice.
--
Mark Montague
mark@catseye.org
reply other threads:[~2011-03-20 4:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4D857C86.1010009@catseye.org \
--to=mark@catseye.org \
--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).