Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner

[Denis Kenzior <denkenz@gmail.com>]

Hi Arend,

On 06/24/2019 03:39 AM, Arend Van Spriel wrote:
> On 6/22/2019 3:44 PM, Marcel Holtmann wrote:
>> Hi Arend,
>>
>>>>>> If the wdev object has been created (via NEW_INTERFACE) with
>>>>>> SOCKET_OWNER attribute set, then limit certain commands only to the
>>>>>> process that created that wdev.
>>>>>>
>>>>>> This can be used to make sure no other process on the system 
>>>>>> interferes
>>>>>> by sending unwanted scans, action frames or any other funny business.
>>>>>
>>>>> The flag is a good addition opposed to having handlers deal with 
>>>>> it. However, earlier motivation for SOCKET_OWNER use was about 
>>>>> netlink multicast being unreliable, which I can agree to. However, 
>>>>> avoiding
>>>> ???  I can't agree to that as I have no idea what you're talking 
>>>> about :)  Explain?  SOCKET_OWNER was introduced mainly to bring down 
>>>> links / scans / whatever in case the initiating process died.  As a 
>>>> side effect it also helped in the beginning when users ran iwd + 
>>>> wpa_s simultaneously (by accident) and all sorts of fun ensued.  We 
>>>> then re-used SOCKET_OWNER for running EAPoL over NL80211.  But 
>>>> 'multicast unreliability' was never an issue that I recall?
>>>
>>> hmm. I tried searching in memory... of my email client but to no 
>>> avail. I somehow recalled that netlink multicast was not guaranteed 
>>> to be delivered/seen by all listeners.
>>>
>>>>> "funny business" is a different thing. Our testing infrastructure 
>>>>> is doing all kind of funny business. Guess we will need to refrain 
>>>>> from
>>>> So you're going behind the managing daemon's back and messing with 
>>>> the kernel state...  I guess the question is why?  But really, if 
>>>> wpa_s wants to tolerate that, that is their problem :)  iwd doesn't 
>>>> want to, nor do we want to deal with the various race conditions and 
>>>> corner cases associated with that.  Life is hard as it is ;)
>>>
>>> That's just it, right. This is what Marcel calls the real 
>>> environment, but is it. The nl80211 is a kernel API and should that 
>>> mean that there must be a managing daemon locking down APIs for other 
>>> user-space tools to use. If I want a user-space app to show a radar 
>>> screen with surrounding APs using scanning and FTM nl80211 commands 
>>> it seems now it has to create a new interface and hope the resources 
>>> are there for it to succeed. Where is my freedom in that? If I am 
>>> using such an app don't you think I don't accept it could impact the 
>>> managing daemon.
>>
>> if you are operating on a shared radio resource you have to have some 
>> way of ensuring that nobody steals resources from you. Having an 
>> external application that will also use scanning and other off-channel 
>> operation will result in a bad experience. Especially if it involves 
>> scanning. Currently we still have 3 or more parties triggering 
>> scanning on nl80211. Essentially they are now fighting for radio time. 
>> You have wpa_supplicant scanning, you have NetworkManager scanning and 
>> you have the UI scanning. Now adding just another application that 
>> just scans at its decided time location / direction finding is not 
>> helping the situation.
> 
> My app was just a hypothetical example. I understand your conundrum, but 
> my point was that you can not know how a system is configured. Now for 
> the SOCKET_OWNER I should say it does not provide you any guarantees. At 
> best it improves your chances. With the nl80211 API being as it is, you 
> can not rule out multiple application controlling the same device. The 
> virtual interfaces can be guarded with SOCKET_OWNER, but in the end 

+1, SOCKET_OWNER is a band-aid.  But in the end this is a fairly simple 
change.   So we can have the managing daemon destroy any existing wdevs 
and re-create them with SOCKET_OWNER set (can we get brcmfmac to support 
this please?).  This at least gives us a chance that nothing will 
inadvertently cause interference.  It won't stop other processes from 
creating other wdevs or other funny business, but that is currently much 
more rare anyway.  In case it really becomes a problem, we can at least 
say "Don't hold it that way."

> there is still one physical device and only if you are lucky you may 
> come across a device with two physical radios, but most of them just 
> have one. If you really want to be in control we should allow only one 
> socket or at least only one "control" socket.

+1.  I've been saying this for a while, there should only be a single 
controlling socket/process, or at least an option for something like 
that.  But the current nl80211 design makes this quite hard.  Hopefully 
the recognition that this is needed will gain traction, until then we're 
stuck with band-aids.

> 
>> If our kernel cfg80211 / nl80211 would be smart enough to handle these 
>> concurrent tasks, I would have little objection to let all clients do 
>> whatever they want, but we don’t have that. I do not want an external 
>> application messing with my planned radio time. And frankly if I am in 
>> the middle of roaming, I don’t want to be delayed because some fancy 
>> radar looking UI decides to start a full spectrum scan or blocks us 
>> via an action frame that times out.
> 
> The have been some efforts to handle concurrent use. For scheduled scan 
> concurrency was added and critical proto primitives allow to temporarily 
> disable scans when user-space needs it, eg. for EAPOL or DHCP exchange.

Which only a single driver seems to support, unfortunately.

Regards,
-Denis

> 
>> With iwd we are moving towards the direction that we are utilizing the 
>> information from access points and surrounding networks to 
>> intelligently scan and reduce the time spent scanning to a minimum. 
>> For us that is the way to improve WiFi experience for Linux.
>>
>> We have been through this with Bluetooth already years ago. You need a 
>> central daemon that watches out for your radio utilization. Doing 
>> anything behind the back of such a daemon is not going to work out 
>> long term. Same applies to 2G/3G/LTE where even more tasks need to be 
>> managed. And even wpa_supplicant has an internal mutex to control 
>> radio time.
> 
> Right. Given how nl80211 works today the only real control of radio time 
> would need to be done in kernel space or go for the one "control" socket 
> approach.
> 
> Regards,
> Arend