linux-kernel - Re: [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel Offload

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: <5fe43b6a-4f16-4a98-b586-51d2964777c0@openvpn.net>
Date: Fri, 15 Nov 2024 16:08:35 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc: Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Shuah Khan <shuah@...nel.org>, sd@...asysnail.net,
 Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 steffen.klassert@...unet.com, antony.antony@...unet.com,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel
 Offload

On 14/11/2024 23:10, Sergey Ryazanov wrote:
> On 14.11.2024 17:33, Antonio Quartulli wrote:
>> On 06/11/2024 02:18, Sergey Ryazanov wrote:
>>> Regarding "big" topics I have only two concerns: link creation using 
>>> RTNL and a switch statement usage. In the corresponding thread, I 
>>> asked Jiri to clarify that "should" regarding .newlink 
>>> implementation. Hope he will have a chance to find a time to reply.
>>
>> True, but to be honest at this point I am fine with sticking to RTNL, 
>> also because we will soon introduce the ability to create 'persistent' 
>> ifaces, which a user should be able to create before starting openvpn.
> 
> Could you share the use case for this functionality?

This is better asked to the users mailing list, but, for example, we 
recently had a discussion about this with the VyOS guys, where they want 
to create the interface and have it fit the various 
firewall/routing/chachacha logic, before any daemon is started.

In OpenVPN userspace we already support the --mktun directive to help 
with this specific use case, so it's a long existing use case.

> 
>> Going through RTNL for this is the best choice IMHO, therefore we have 
>> an extra use case in favour of this approach (next to what Jiri 
>> already mentioned).
> 
> In absence of arguments it's hard to understand, what's the "best" 
> meaning. 

well, that's why I added "IMHO" :)

> So, I'm still not sure is it worth to split uAPI between two 
> interfaces. Anyway, it's up to maintainers to decide is it mergeable in 
> this form or not. I just shared some arguments for the full management 
> interface in GENL.

well, doing it differently from all other virtual drivers also requires 
some important reason IMHO.

Anyway, I like the idea that iproute2 can be used to create interfaces, 
without the need to have another userspace tool for that.

Regards,


-- 
Antonio Quartulli
OpenVPN Inc.