netdev - Re: [Patch 4/5] Network Drop Monitor: Adding drop monitor implementation & Netlink protocol

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Apr 2009 15:21:45 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	herbert@...dor.apana.org.au, nhorman@...driver.com,
	zbr@...emap.net, netdev@...r.kernel.org, kuznet@....inr.ac.ru,
	pekkas@...core.fi, jmorris@...ei.org, yoshfuji@...ux-ipv6.org
Subject: Re: [Patch 4/5] Network Drop Monitor: Adding drop monitor implementation
 & Netlink protocol

David Miller wrote:
> From: Herbert Xu <herbert@...dor.apana.org.au>
> Date: Thu, 2 Apr 2009 23:30:42 +0800
> 
>> On Thu, Apr 02, 2009 at 05:14:50PM +0200, Patrick McHardy wrote:
>>> I'd prefer that as well. The only reason to do this is to save a few
>>> bytes and cycles for attribute encapsulation. I don't think this
>>> matters at all, judging by the fact that I've never seen a userspace
>>> implementation using message batching, the current users don't seem
>>> to care about performance *that* much.
>> OK, let's all just keep an eye out for new struct users and see
>> how it goes.
> 
> It might be about time to start working on netlink-2 seriously.
> :-)
> 
> We can start treating it like a real protocol, firmly define
> the endianness of everything to kill all the over-the-wire
> issues, etc. and deal with this 4-byte-align stuff as well.

We could add a setsockopt option for userspace to specify "version 2"
operation. The netlink attributes helpers would need to be aware of
the currently used protocol version and could transparently choose
a different encoding (also taking care of endianess etc). For the
case of one value per attribute this should be a straight-forward
conversion. In case of structures that contain values with different
endianness, we'll probably need to define a new encoding (ideally
also one attribute per value) for version 2.

I'd also suggest to get rid of the 64k attribute and message size
limit at the same time, this is making it quite hard to support
transactional semantics for large updates (f.i. for nf_tables sets).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html