netdev - Re: [RFC PATCH] netlink: Increase netlink dump skb message 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20110425.235600.104065244.davem@davemloft.net>
Date:	Mon, 25 Apr 2011 23:56:00 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	gregory.v.rose@...el.com, netdev@...r.kernel.org,
	bhutchings@...arflare.com
Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 26 Apr 2011 08:33:17 +0200

> Le lundi 25 avril 2011 à 15:01 -0700, Greg Rose a écrit :
>> The message size allocated for rtnl info dumps was limited to a single page.
>> This is not enough for additional interface info available with devices
>> that support SR-IOV.  Check that the amount of data allocated is sufficient
>> for the amount of data requested.
>> 
>> Signed-off-by: Greg Rose <gregory.v.rose@...el.com>
>> ---
>> 
>>  include/linux/rtnetlink.h |    1 +
>>  net/core/rtnetlink.c      |    6 ++++++
>>  net/netlink/af_netlink.c  |   37 +++++++++++++++++++++++++++++++------
>>  3 files changed, 38 insertions(+), 6 deletions(-)
>> 
> 
> Hmm, thats a hack, because netlink_dump() is generic and you add
> something very specific.

You also can't do this without breaking applications.

We've trained every single netlink library out there about this message size
formula, so they know that if you allocate at least 8192 bytes for a recvmsg()
call they can receive fully any single netlink message.

And they must be able to make assumptions like this, otherwise they
cannot know how to reliably be able to receive a netlink message in
it's entirety in a generic fashion.

So one must not attack this problem from this angle.

It is absolutely necessary to find some way to report the VF
information, out of band, instead of trying to make the message
larger.

Needing more than 8K to get a dump of a single device over netlink is
absolutely rediculious, this VF stuff was poorly designed.  If has to
be fixed and the current stuff marked deprecated.
--
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