Hi Paul,

I'm not sure how to verify this bug. I checked the code and only thing, I found, is this:

# libreswan-3.27-9.el8.src/libreswan-3.27
1040>> grep af_key -r *
programs/_stackmanager/_stackmanager.in:         xfrm4_tunnel xfrm4_mode_beet esp4 esp6 ah4 ah6 af_key \
programs/_stackmanager/_stackmanager.in:     xfrm4_mode_beet esp4 esp6 ah4 ah6 af_key ip_vti
programs/_realsetup.bsd/_realsetup.in:           lsmod 2>&1 | grep "^af_key" > /dev/null && rmmod af_ke

# libreswan-3.28-1.el8.src/libreswan-3.28
1042>> grep af_key -r *
CHANGES:* _stackmanager: Do not attempt to load PF_KEY (af_key.ko) module [Paul]
programs/_realsetup.bsd/_realsetup.in:          lsmod 2>&1 | grep "^af_key" > /dev/null && rmmod af_key

Is this the only change in the code?

There are some more changes.

We used to detect the XFRM/IPsec kernel code by checking for /proc/net/pfkey which is provided by the kernel module af_key.ko. We changed that upstream to use /proc/net/xfrm_stat instead. However, that is provided only when compiled with CONFIG_XFRM_STATISTICS, which is true for fedora/redhat but not for older Debian/Ubuntu systems. So we then switched upstream to checking the XFRM/IPsec kernel code by checking for /proc/sys/net/core/xfrm_acq_expires

For the base test, you should start the ipsec service and bring up a tunnel. If that works, then there is no regresion on XFRM/IPsec stack detection.

But there is one issue. The af_key.ko module (provided by CONFIG_NET_KEY) is getting auto-loaded due to other kernel modules related to XFRM. So we still get this deprecates module loaded by accident. I filed a bug for that for the kernel people to either fix the auto-load or to just disable CONFIG_NET_KEY entirely (both libreswan and strongswan no longer need it, only the ancient ipsec-tools which we haven't supported since RHEL5 needs it)

So if you want to test that libreswan won't break on any future kernel where CONFIG_NET_KEY is disabled or prevented from auto-loading, you should do this additional test:

systemctl stop ipsec
rmmod af_key
rm -f /lib/modules/`uname -r`/kernel/net/key/af_key.ko*
depmod -a
systemctl start ipsec
[bring up the tunnel again]

If that works, then you confirmed that libreswan runs fully without CONFIG_NET_KEY (af_key)


The related kernel bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1706183

note that the original reason for ensuring af_key no longer loads, is that there have been reports of 10% CPU load being wasted by the kernel because for XFRM/netlink messages it will create the equivalent PF_KEYv2 messages if the af_key.ko module is loaded, despite there being no process that is listening for PFKEYv2 kernel messages.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3391