kernel_xfrm: record extended ack from netlink response

[ueno]

This enables pluto to log any error message reported through extended ACK attributes[1] in a netlink response, to make diagnostic easier when an error occurs. Suggested by Sabrina Dubroca.

1. https://docs.kernel.org/userspace-api/netlink/intro.html#ext-ack

[ueno]

I'm currently testing this using the KVM tests (e.g., pluto/ikev2-algo-sha2-03), though haven't managed to receive ACK TLVs, even if NETLINK_{CAP,EXT}_ACKS is set with setsockopt. Perhaps the support might not be part of the kernel 6.8.9?

[letoams]

On Tue, 21 May 2024, Daiki Ueno wrote: I'm currently testing this using the KVM tests (e.g., pluto/ikev2-algo-sha2-03), though haven't managed to receive ACK TLVs, even if NETLINK_{CAP,EXT}_ACKS is set with setsockopt. Perhaps the support might not be part of the kernel 6.8.9?

So I have two questions: 1) What happens when we try to enable this on kernels that do not support this? Will it be ignored or throw an error? 2) When was this support added to the kernel? e.g. is it safe for us to assume the support is there? (eg 2.x, 3.x? 6.x ?) Paul

[qsn]

6.8.9 should work for your tests, but you will only get the extack response if your netlink request is invalid and the state/policy can't be installed. This may not be easy to trigger since I expect libreswan to generate correct requests in almost all cases. I'm assuming you validate strings taken from the user's config before converting them into netlink requests, so generating a request with a bogus ICV length or non-existent algorithm ("foobar" instead of "rfc4106(gcm(aes))", or some algorithm that's not supported on the current kernel), or a bogus IP mask length, or 42 instead of XFRM_MODE_TUNNEL, etc, is likely not easy.

The kernel's IPsec implementation has been providing extacks since 6.2 (the bulk of the changes went into 6.1), but extacks existed for a long time before that (4.12, see merge commit).

In case the kernel just doesn't support extack, the setsockopt enabling extack on the socket should fail and do nothing (and the return value is ignored in this patch). No extack information will be returned in the kernel's answer.

In case the kernel supports extack but xfrm doesn't fill that information, the userspace application will just not get any extra details on why the request failed. This can also happen on 6.2+ kernels if the kernel does not explicitly set the error (which I think is the case for all ENOMEM type of situations, because I didn't see any value in adding a string that would basically repeat ENOMEM's meaning - and maybe a few other cases).

[ueno]

I've confirmed that, if I add req.p.mode = 42 in netlink_add_sa, I get:

ERROR: "westnet-eastnet-ipv4-psk-ikev2" #2: netlink response for Add SA esp.b455
0ed8@192.1.2.23: Invalid argument (errno 22)
"westnet-eastnet-ipv4-psk-ikev2" #2: netlink ext_ack: Unsupported mode

from ikev2-algo-sha2-01 test. Not sure how this can be exercised properly in the test suite though.

[qsn]

I've confirmed that, if I add req.p.mode = 42 in netlink_add_sa, I get:

ERROR: "westnet-eastnet-ipv4-psk-ikev2" #2: netlink response for Add SA esp.b455
0ed8@192.1.2.23: Invalid argument (errno 22)
"westnet-eastnet-ipv4-psk-ikev2" #2: netlink ext_ack: Unsupported mode

Nice :)

from ikev2-algo-sha2-01 test. Not sure how this can be exercised properly in the test suite though.

Does libreswan prevent the combinations of options that the kernel doesn't support? AH and IPcomp don't work with UDP encap or TFCPAD, IPcomp only works with transport/tunnel mode (not BEET), TFCPAD only works in tunnel mode, NIC offload only works with ESP but not AH (and for crypto offload, not with UDP/TCP encap or TFCPAD). If some of those are considered valid by libreswan, the kernel should reject them and return an extack message.

[letoams]

On May 24, 2024, at 09:23, qsn ***@***.***> wrote: Does libreswan prevent the combinations of options that the kernel doesn't support? AH and IPcomp don't work with UDP encap or TFCPAD, IPcomp only works with transport/tunnel mode (not BEET), TFCPAD only works in tunnel mode, NIC offload only works with ESP but not AH (and for crypto offload, not with UDP/TCP encap or TFCPAD). If some of those are considered valid by libreswan,

Nope, libreswan won’t let you do those. The easiest way to test this is to add an —impair that sets a bogus value.

[cagney]

testing

[cagney]

I'll change:

@@ -515,6 +555,7 @@ static bool sendrecv_xfrm_msg(struct nlmsghdr *hdr,
                 */
                ldbg(logger, "%s() netlink response for %s %s included non-error error",
                     __func__, description, story);
+               llog_ext_ack(DEBUG_STREAM, logger, &rsp.n);
                /* ignore */
        }

to

  if (DBGP(DBG_LOG)) {
    LDBG_log(logger, ...)
    llog_ext_ack(DEBUG_STREAM, ...)
}

so it doesn't always debug log

[cagney]

pushed