netdev - Re: [PATCH net-next v7 03/25] net: introduce OpenVPN Data Channel Offload (ovpn)

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: <02420241-98a9-47dc-97a7-d3c1fad76573@openvpn.net>
Date: Fri, 20 Sep 2024 11:46:34 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: andrew@...n.ch, antony.antony@...unet.com, edumazet@...gle.com,
 kuba@...nel.org, netdev@...r.kernel.org, pabeni@...hat.com,
 ryazanov.s.a@...il.com, sd@...asysnail.net, steffen.klassert@...unet.com
Subject: Re: [PATCH net-next v7 03/25] net: introduce OpenVPN Data Channel
 Offload (ovpn)

Hi,

On 20/09/2024 11:32, Kuniyuki Iwashima wrote:
> From: Antonio Quartulli <antonio@...nvpn.net>
> Date: Thu, 19 Sep 2024 13:57:51 +0200
>> Hi Kuniyuki and thank you for chiming in.
>>
>> On 19/09/2024 07:52, Kuniyuki Iwashima wrote:
>>> From: Antonio Quartulli <antonio@...nvpn.net>
>>> Date: Tue, 17 Sep 2024 03:07:12 +0200
>>>> +/* we register with rtnl to let core know that ovpn is a virtual driver and
>>>> + * therefore ifaces should be destroyed when exiting a netns
>>>> + */
>>>> +static struct rtnl_link_ops ovpn_link_ops = {
>>>> +};
>>>
>>> This looks like abusing rtnl_link_ops.
>>
>> In some way, the inspiration came from
>> 5b9e7e160795 ("openvswitch: introduce rtnl ops stub")
>>
>> [which just reminded me that I wanted to fill the .kind field, but I
>> forgot to do so]
>>
>> The reason for taking this approach was to avoid handling the iface
>> destruction upon netns exit inside the driver, when the core already has
>> all the code for taking care of this for us.
>>
>> Originally I implemented pernet_operations.pre_exit, but Sabrina
>> suggested that letting the core handle the destruction was cleaner (and
>> I agreed).
>>
>> However, after I removed the pre_exit implementation, we realized that
>> default_device_exit_batch/default_device_exit_net thought that an ovpn
>> device is a real NIC and was moving it to the global netns rather than
>> killing it.
>>
>> One way to fix the above was to register rtnl_link_ops with netns_fund =
>> false (so the ops object you see in this patch is not truly "empty").
>>
>> However, I then hit the bug which required patch 2 to get fixed.
>>
>> Does it make sense to you?
>> Or you still think this is an rtnl_link_ops abuse?
> 
> The use of .kind makes sense, and the change should be in this patch.

Ok, will add it here and I will also add an explicit .netns_fund = false 
to highlight the fact that we need this attribute to avoid moving the 
iface to the global netns.

> 
> For the patch 2 and dellink(), is the device not expected to be removed
> by ip link del ?  Setting unregister_netdevice_queue() to dellink() will
> support RTM_DELLINK, but otherwise -EOPNOTSUPP is returned.

For the time being I decided that it would make sense to add and delete 
ovpn interfaces via netlink API only.

But there are already discussions about implementing the RTNL 
add/dellink() too.
Therefore I think it makes sense to set dellink to 
unregister_netdevice_queue() in this patch and thus avoid patch 2 at all.


Thanks.

Regards,

> 
> 
>>
>> The alternative was to change
>> default_device_exit_batch/default_device_exit_net to read some new
>> netdevice flag which would tell if the interface should be killed or
>> moved to global upon netns exit.
>>
>> Regards,
>>

-- 
Antonio Quartulli
OpenVPN Inc.