linux-kernel - Re: [RFC 1/1] net: introduce OpenVPN Data Channel Offload (ovpn-dco)

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: <684e4a61-3fe3-00ac-42d2-213e501f14d4@openvpn.net>
Date:   Thu, 4 Aug 2022 09:34:13 +0200
From:   Antonio Quartulli <antonio@...nvpn.net>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/1] net: introduce OpenVPN Data Channel Offload (ovpn-dco)

On 03/08/2022 18:19, Stephen Hemminger wrote:
> On Wed, 3 Aug 2022 17:48:45 +0200
> Antonio Quartulli <antonio@...nvpn.net> wrote:
> 
>> There must have been some confusion - sorry about that.
>>
>> The repository I linked in my previous email is this very same driver
>> packaged as "out-of-tree" module (i.e. for people running a kernel that
>> does not yet ship ovpn-dco) and contains some compat wrapper.
>>
>>
>> The driver I have submitted to the list is 100% standalone and does not
>> contain any compat code.
>>
>>
>> The only extra component required to do something useful with this
>> driver is the OpenVPN software in userspace.
> 
> 
> Good to here thanks.
> I wonder if there is any chance of having multiple VPN projects
> using same infrastructure. There seems to be some parallel effort
> in L2TP, OpenVPN, etc.

Thanks for rising this point, Stephen.

I also believe it would be nice to re-use as much infrastructure as 
possible (I always strive to reduce code duplication, while keeping core 
building blocks simple and re-usable), however, it seems that the 
various implementations currently do not share much logic.

What could be shared is already shared (i.e. crypto, napi, gso, netdev, 
etc). Handling the data traffic is something that can hardly be shared 
due to different packet manipulation (i.e. encapsulation).

One area that could still be worth exploring might be the queuing 
mechanism that handles packet reception+decryption and 
encryption+transmission. If we factor out the protocol specific bits, we 
might be able to make the high level logic common.

However, so far all my attempts did not lead to anything that could be 
implemented in a reasonable manner.

Still, I believe this is something we could work on in the medium/long-term.

Regards,

-- 
Antonio Quartulli
OpenVPN Inc.