[SRU][PULL][F] merge upstream wireguard

[Thadeu Lima de Souza Cascardo]

On Wed, Dec 07, 2022 at 03:33:02PM +0100, Andrea Righi wrote:
> On Wed, Dec 07, 2022 at 03:09:05PM +0100, Stefan Bader wrote:
> > On 06.12.22 11:57, Andrea Righi wrote:
> > > BugLink: https://bugs.launchpad.net/bugs/1998902
> > > 
> > > [Impact]
> > > 
> > > In older kernels, like focal, Wireguard used to be maintained as an
> > > external module (wireguard-dkms). This dkms is not maintained anymore,
> > > but upstream maintainer periodically provides backported patches for
> > > older kernels (like 5.4) in this git repository
> > > https://git.zx2c4.com/wireguard-linux.
> > > 
> > > In order to properly support Wireguard with all the recent security
> > > updates, fixes, etc. it would be more efficient for us to apply the
> > > backported patch set officially provided by the upstream maintainer,
> > > instead of maintaining these changes in a separate dkms.
> > > 
> > > [Test case]
> > > 
> > > We need to figure out a proper test case to verify that wireguard is
> > > applied and it's working correctly.
> > > 
> > > Right now the best option is to verify the availability of the
> > > wireguard.ko module and run the kernel selftests in
> > > tools/testing/selftests/wireguard/ (specifically
> > > ./tools/testing/selftests/wireguard/netns.sh - we can just run it
> > > directly, but it requires iperf3 and ncat installed and a
> > > `modprobe nf_conntrack` before starting the test).
> > > 
> > > [Fix]
> > > 
> > > Apply the backported wireguard patch set provided by the upstream
> > > maintainer as UBUNTU SAUCE patches (patch set available in
> > > https://git.zx2c4.com/wireguard-linux branch backport-5.4.y).
> > 
> > Not really liking that much. Mostly the part of changes which modify crypto
> > and the one or two places that change networking code in general. Not looked
> > closer but it feels like replacing an unmaintainable driver with an
> > unmaintainable kernel which has to be supported at least another 8y.
> > There probably is also the question how this works out for fips (since that
> > has a kind of lockdown for crypto).
> > This will also introduce a huge amount of change which is not covered by
> > upstream stable. At least things should be separated into its own directory
> > subdomain.
> > But generally, this seems to become a burden to maintain either way. In
> > which case I would more tend to maintain what is already there and settled
> > to be working.
> > 
> > -Stefan
> 
> Do you think a separate derivative would help to reduce the risk of
> conflicts / bugs / additional maintenance in the generic kernel?
> 
> Another derivative probably means even more work, but it wouldn't slow
> down stable updates in generic. So, linux-wireguard (for example) would
> be like a compromise to provide something to the wireguard users that is
> more up-to-date than what we have, but not always up-to-date like the
> generic kernel. And I'm still not sure if I like this, just throwing
> ideas for now to see if we can figure out something acceptable...
> 

At this point, if you are installing a specific kernel, why not install a 5.15
kernel on Focal. And if you are in Bionic, you should be happy with what you
already have with the 5.4 kernel and not willing to get anything else but very
important security updates starting next April. Though there will be much more
than only security updates on the 5.4 kernel for another 2 years then. Just
not this one.

Cascardo.

> -Andrea
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team