netdev - enhancing nfnetlink stats [was Re: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 23 Mar 2016 13:28:55 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	"Yigal Reiss (yreiss)" <yreiss@...co.com>
Cc:	Florian Westphal <fw@...len.de>,
	"'netdev@...r.kernel.org'" <netdev@...r.kernel.org>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>
Subject: enhancing nfnetlink stats [was Re: [PATCH net-next] change nfqueue
 failopen to apply also to receive message buffer in addition to queue size]

On Wed, Mar 23, 2016 at 12:04:28PM +0000, Yigal Reiss (yreiss) wrote:
> >>  -	seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %2d\n", +
> >>  seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %5u %5u %2d\n",
> > Problematic since it changes layout of a file we unfortunately
> > have to view as uapi.  I would prefer if we could leave the proc
> > file alone and not add any new stats counters for this, unless
> > there is a good argument for doing so.
>
> So my arguments are that there in order to fine tune a system it is
> required to know about the existence and number of packets that went
> under the radar. As I wrote ENOBUF does not answer all these needs.
> I understand it is problematic to change uapi. Tried to minimize
> incompatibility by keeping the order of arguments. I'll probably use
> a patch to proc any way. Please let me know if you think there is a
> point in proposing this patch or is it a "no-no" from kernel's
> perspective.

I'd suggest you extend the existing nfnetlink_queue infrastructure so
we retrieve these statistics through netlink, ie. add the
NFQNL_MSG_STATS message. Then, extend nft so we can list them via:

# nft list queues
... [ stats here ] ...