All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chenbo Feng <chenbofeng.kernel@gmail.com>
To: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
	pablo@netfilter.org
Cc: kernel-team@android.com, Lorenzo Colitti <lorenzo@google.com>,
	maze@google.com, Chenbo Feng <fengc@google.com>
Subject: [PATCH net-next iptables] Rework the xt_quota module
Date: Mon,  1 Oct 2018 18:23:06 -0700	[thread overview]
Message-ID: <1538443388-6881-1-git-send-email-chenbofeng.kernel@gmail.com> (raw)

From: Chenbo Feng <fengc@google.com>

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current xt_quota module uses an additional kernel struct to store
the remaining quota of an iptables match and does not expose it to
userspace. The major flaw of the current implementation is the quota
will be reset whenever an unrelated rule gets updated in the same table
as an xt_quota rule exists. Such behavior makes xt_quota rules not very
useful in a dynamically changing iptables setup.

To fix the problem above, a new remain field is introduced to replace
the kernel struct pointer. It is used in the kernel as an atomic64_t and
treated as an __aligned_u64 when it is copied to userspace. Since the
struct xt_quota_info uses __aligned_u64 to record the quota, it is
guaranteed the padding space at the end of the current struct is 64bit
wide even on a 32bit machine. So we can safely pass the current quota
from kernel to userspace without adding an extra revision to the
xt_quota module. Userspace can set the remaining quota with new
"--remain x" option when restoring a rule that is previously saved.

For general quota rule insertion/deletion, the user can choose whether
to specify the remaining quota or not. If a quota rule is inserted
without specifying the remaining quota, it will be set to the original
quota. As for rule deletion, the remaining part is not matched since it
is a dynamically changing field when there is live networking traffic
and makes no sense to specify the exact value of current remaining
quota.

For an old kernel with new iptables with this fix, the remain field will
not get copied into kernel memory because of the usersize definition in
kernel xt_quota module. So it will still act the same as old xt_quota
module. When dumping or saving the iptables rule, the kernel pointer
will not get copied to userspace and iptables will ignore the remaining
field if it is just zero initilized memory.

For a kernel with fix running against old iptables, insertion or
deletion of an unrelated rule no longer resets the quota since the
remain field will be copied out of kernel and updated back during the
rule insertion/deletion process.

kernel changes:

Chenbo Feng (1):
  netfilter: xt_quota: fix the behavior of xt_quota module

 include/uapi/linux/netfilter/xt_quota.h |  8 +++--
 net/netfilter/xt_quota.c                | 55 +++++++++++++--------------------
 2 files changed, 27 insertions(+), 36 deletions(-)

iptables changes:

Chenbo Feng (1):
  extensions: libxt_quota: Allow setting the remaining quota

 extensions/libxt_quota.c           | 23 +++++++++++++++++++++--
 include/linux/netfilter/xt_quota.h |  8 +++++---
 2 files changed, 26 insertions(+), 5 deletions(-)

-- 
2.7.4

             reply	other threads:[~2018-10-02  8:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02  1:23 Chenbo Feng [this message]
2018-10-02  1:23 ` [PATCH iptables] extensions: libxt_quota: Allow setting the remaining quota Chenbo Feng
2018-10-08 23:16   ` Pablo Neira Ayuso
2018-10-02  1:23 ` [PATCH net-next] netfilter: xt_quota: fix the behavior of xt_quota module Chenbo Feng
2018-10-02  7:59   ` Pablo Neira Ayuso
2018-10-02  8:24     ` Maciej Żenczykowski
2018-10-02  8:25       ` Maciej Żenczykowski
2018-10-02 10:11       ` Pablo Neira Ayuso
2018-10-02 10:15         ` Pablo Neira Ayuso
2018-10-02 10:38           ` Maciej Żenczykowski
2018-10-02 10:51             ` Pablo Neira Ayuso
2018-10-02 10:52               ` Pablo Neira Ayuso
2018-10-02 17:45               ` Chenbo Feng
2018-10-02 18:15                 ` Pablo Neira Ayuso
2018-10-02 18:28                   ` Chenbo Feng
2018-10-02 18:43                     ` Pablo Neira Ayuso
2018-10-02 22:22                       ` Maciej Żenczykowski
2018-10-03  9:19   ` Pablo Neira Ayuso
2018-10-03  9:26     ` Maciej Żenczykowski
2018-10-03  9:28       ` Pablo Neira Ayuso
2018-10-03 15:37   ` 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=1538443388-6881-1-git-send-email-chenbofeng.kernel@gmail.com \
    --to=chenbofeng.kernel@gmail.com \
    --cc=fengc@google.com \
    --cc=kernel-team@android.com \
    --cc=lorenzo@google.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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.