From: Florian Westphal <fw@strlen.de>
To: Krishna Kumar <krkumar2@in.ibm.com>
Cc: kaber@trash.net, pablo@netfilter.org, vivk@us.ibm.com,
svajipay@in.ibm.com, fw@strlen.de,
netfilter-devel@vger.kernel.org, sri@us.ibm.com
Subject: Re: [v3 PATCH 1/1] netfilter: Add fail-open support.
Date: Tue, 22 May 2012 16:38:58 +0200 [thread overview]
Message-ID: <20120522143858.GB14029@breakpoint.cc> (raw)
In-Reply-To: <20120522121048.880.22605.sendpatchset@localhost.localdomain>
Krishna Kumar <krkumar2@in.ibm.com> wrote:
> Implement a new "fail-open" mode where packets are not dropped
> upon queue-full condition. This mode can be individually enabled
> or disabled per queue using netlink NFAQ_CFG_FLAGS & NFAQ_CFG_MASK
> attributes.
>
> NFQA_CFG_QUEUE_MAXLEN, /* __u32 */
> + NFQA_CFG_MASK, /* identify which flags to change */
> + NFQA_CFG_FLAGS, /* value of these flags (__u32) */
__be32?
I see that QUEUE_MAXLEN gets ntohl treatment, too....
> __NFQA_CFG_MAX
> };
> #define NFQA_CFG_MAX (__NFQA_CFG_MAX-1)
>
> +/* Flags for NFQA_CFG_FLAGS */
> +#define NFQA_CFG_F_FAIL_OPEN (1 << 0)
> +
> #endif /* _NFNETLINK_QUEUE_H */
> diff -ruNp org/net/netfilter/core.c new/net/netfilter/core.c
> --- org/net/netfilter/core.c 2012-05-22 08:45:32.651608253 +0530
> +++ new/net/netfilter/core.c 2012-05-22 17:35:51.294216873 +0530
> @@ -163,6 +163,31 @@ repeat:
> return NF_ACCEPT;
> }
>
> +/*
> + * Handler was not able to enqueue the packet, and returned ENOSPC
> + * since "fail-open" was enabled. We temporarily accept the skb, or
> + * each segment for a segmented skb, and then free up the header.
> + */
> +static void handle_fail_open(struct sk_buff *skb,
> + int (*okfn)(struct sk_buff *))
> +{
> + struct sk_buff *segs;
> + bool gso;
> +
> + segs = skb->next ? : skb;
> + gso = skb->next != NULL;
> +
> + do {
> + struct sk_buff *nskb = segs->next;
> +
> + segs->next = NULL;
> + okfn(segs);
> + segs = nskb;
> + } while (segs);
> +
> + if (gso)
> + kfree_skb(skb);
> +}
I don't understand why this is needed at all.
Conceptually, what you're doing is identical to the
--nfqueue-bypass feature, so it should be enough to change
> @@ -199,10 +226,18 @@ next_hook:
> if (err == -ESRCH &&
> (verdict & NF_VERDICT_FLAG_QUEUE_BYPASS))
> goto next_hook;
> + if (err == -ENOSPC) {
> + failopen = 1;
> + goto next_hook;
> + }
> kfree_skb(skb);
to
if (err == -ENOSPC || (err == -ESRCH && (verdict & NF_VERDICT_FLAG_QUEUE_BYPASS))
goto next_hook;
[ or, take advantage of the existing -ECANCELED and have the queueing
backend return that if queue is full and fail-open is enabled ]
Yes, that means that if the userspace ruleset is
-j NFQUEUE
-j DROP
then your packets will be dropped even if the userspace application
enables failopen.
But thats a feature, since you could also do
-j NFQUEUE
-m limt ... -j LOG --log-prefix "queue overflow"
or play extra games wrt. "drop if established, CONNMARK
for future bypass if --ctstate NEW", etc.
If its a requirment for you that userspace can force ACCEPT
regardless of ruleset, then perhaps it might be better to
add a separate "default verdict" option and invoke
nf_reinject() directly from the qeueueing backend instead
of passing the fail-open information back to nf_hook_slow?
> + flags = nla_data(nfqa[NFQA_CFG_FLAGS]);
> + mask = nla_data(nfqa[NFQA_CFG_MASK]);
nla_get_be32()?
[ _u32 would make more sense to me, but other attributes are be32 too,
so I'm ok with it ]
> - if (err == 0)
> +
> + if (err == 0) {
> queued++;
> - else
> + } else if (err == -ENOSPC) {
> + /* Queue failed due to queue-full and handler is
> + * in "fail-open" mode.
> + */
> + segs->next = nskb;
> + skb->next = segs;
> + break;
> + } else {
> kfree_skb(segs);
> + }
> segs = nskb;
> } while (segs);
>
> - if (queued) {
> + if (queued && err != -ENOSPC) {
> kfree_skb(skb);
> return 0;
> }
Similarily, this shouldn't be needed either any more since you
no longer need to check for -ENOSPC (existing --queue-bypass behaviour
should handle your case, too).
next prev parent reply other threads:[~2012-05-22 14:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 12:10 [v3 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE Krishna Kumar
2012-05-22 12:10 ` [v3 PATCH 1/1] netfilter: Add fail-open support Krishna Kumar
2012-05-22 14:38 ` Florian Westphal [this message]
2012-05-23 6:45 ` Krishna Kumar2
2012-05-23 7:54 ` Florian Westphal
2012-05-23 14:11 ` Krishna Kumar2
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=20120522143858.GB14029@breakpoint.cc \
--to=fw@strlen.de \
--cc=kaber@trash.net \
--cc=krkumar2@in.ibm.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=sri@us.ibm.com \
--cc=svajipay@in.ibm.com \
--cc=vivk@us.ibm.com \
/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).