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

[Andrea Righi]

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...

-Andrea