netdev - Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces

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]

Message-ID: <1462811585.18382.22.camel@strongswan.org>
Date:	Mon, 09 May 2016 18:33:05 +0200
From:	Martin Willi <martin@...ongswan.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from
 non-initial namespaces


> > Moving the radio back to the creators namespace would be the most
> > consistent behavior, so I'll check how difficult such a reverse
> > lookup is. We then would delete the radio only if it is in the
> > creators namespace, or if the creators namespace is gone. Does that
> > make sense?

> It does make sense, but it does also feel a bit complicated. 

Yes, and proper locking gets difficult when using cfg80211_set_netns(),
which can sleep. This would probably need larger changes in the locking
code, but that's IMO not worth the effort.

> Perhaps just special-case the init_net case for consistency with the
> existing behaviour, and reserve netgroup 0 for that so we can easily
> check for it?

I'll do that in a v2, following immediately.

> > I suspect you should be defining a structure that currently 
> > contains one integer member. Something (maybe a compile time 
> > assert) needs to check that buffer space you are accessing (where 
> > ever it is) is large enough.
> 
> It does look a bit awkward, but there's no value in having a struct -
> you still have an opaque pointer here and cast it to something whose
> size you assume to be present... it really makes no difference.

I agree there is no added safety when using a struct; Nonetheless have
I added one in v2, and is it just for any future member additions.

Best regards
Martin