netdev - Re: multicasting netlink messages to groups

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: <1183557241.3812.20.camel@johannes.berg>
Date:	Wed, 04 Jul 2007 15:54:01 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	netdev <netdev@...r.kernel.org>, jamal <hadi@...erus.ca>,
	Patrick McHardy <kaber@...sh.net>, Thomas Graf <tgraf@...g.ch>
Subject: Re: multicasting netlink messages to groups > 31 from userspace

On Wed, 2007-07-04 at 16:04 +0400, Evgeniy Polyakov wrote:
> On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg (johannes@...solutions.net) wrote:
> > Does anybody have any better ideas?

> Why don't you want to reserve a set of bits in group number, which means 
> 'allow to work with unpriveledged users', that bits should not cross existing 
> users (hardcoded in various files in kernel), all new code can use that
> groups.

Uh wait, we're confusing two issues here. This idea actually makes good
sense, although it'd have to be two bits (allow unpriv users to recv,
allow unpriv users to send), limiting the groups to 2^30-1. Fine with
me.

However, the actual issue I wanted to address with this mail is that we
cannot have userspace send to groups > 32. However, your idea above can
equally well apply here; we could say some bit in the nl_groups field is
reserved and that if that bit is set the other bits form the group
number to send to instead of a bitfield where the highest group is sent
to. That should work fine, both limits the number of available groups to
2^30 respectively 2^31 but that's not an issue.

The thing with actually trying to fix this issue now is that when we
have generic netlink and multicast group registrations, we'll have
userspace programs sending to a multicast group using nl_groups =
(1<<group.id) and then group.id grows > 32 if a whole bunch of other
groups were registered before, and it all messes up. Hence we actually
have to address this issue well before userspace starts using the
generic netlink multicast API.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)