[Swan-dev] kernel_ops
Antony Antony
antony at phenome.org
Thu Mar 12 22:07:25 UTC 2020
On Tue, Feb 25, 2020 at 10:04:22AM -0500, Andrew Cagney wrote:
> The libreswan's code base has reached an interesting point. We
> support (or are at least trying to support :-) two network interfaces:
>
> - BSDKAME
> - XFRM (does xfrmi qualify as a separate stack?)
no. xfrmi can't work without xfrm. It is just creates an interface for
routed vpn.
> (ok, there's a third - nokernel but I'm struggling to see its value -
> on linux the network stack is prewired to xfrmi etc) and the kernels:
>
> - BSD*
> - Linux
>
> however currently only one combination is valid:
>
> - xfrm + linux
> - kame + bsd
I see DPDK getting popular. AFIK both BSD and Linux would support for it.
On Linux DPDK + VPP on Intel Xeon scalable processors looks very promising
. So, I 'predict' libreswan DPDK support soon! AFKIK DPDK support can co
exist with the native stack. On Linux a connection could choose xfrm or dpdk
stack for ESP, data plane path.
> So, notionally, kernel_ops is no longer required. While I'm assuming
Wonder what would happen when DPDK get addded to both Linux and BSD.
> that we're not about to delete it I do think its worth asking its
> purpose - like for any portable kernel dependent software the we
> struggle with the questions:
>
> - does this go in kernel_ops - "kernel" for network interface ops
> - does this go in kernel_{bsd,linux} - how we have "kernel" for os? ops, hmm,
> - does this get wrapped in in #ifdef
>
> So, what is a "kernel" - we've got two - and as a rule, what should live where?
that is good question. My thoughts are start seperating kernel ops along the
following lines.
1. IKE sockets listen and send (network interfaces) - sockets + netlink
cb???
2. address secltion addconn (left=%defaultroute) - netlink
3. address selection using sockets (left=%eth1) - socket calls
4. address changes (MOBIKE) - netlink RTM callbacks.
5. xfrm SADB and SPDB manipulations - netlink add SA, update SA, mobike
migration, delete SA, xfrmi, traffic status, and call backs for acquire,
timer/byte count expirations.
6. creating ipv6 holes - netlink
7. detecting xfrm ofload - ioctl, possibly also netlink.
8. adding address and refcounting them, leftinterface-ip - netlink
9. in the future we may add route detection - netlink RTM_ call backs. If
addconn run before default route is added that connection would not work
when default route get added?
Currently many of these are grouped together with kernel/xfrm + netlink.
> To help things, here are two examples, I don't see either as bad just
> illustrations of the compromise:
>
> - (pre-my recent changes, I should probably rename process_... to merge_...):
>
> mark_ifaces_dead();
> kernel_ops->process_raw_ifaces(find_raw_ifaces4());
> kernel_ops->process_raw_ifaces(find_raw_ifaces6());
>
> find_raw_ifaces[46]() is presumably os specific (and should be
> merged); however, is process_raw_ifaces() really part of the network
> interface or part of the os? While BSD uses all the parameters passed
yes. I would call IKE send and receive.
> in, linux does some extra filtering, and I'm not sure why it can't
Some of the filtering is to avoid IKE over ipsecX interfaces(from the KLIPs
era) I think those are useful also with xfrmi too.
> simply be done in find_raw_ifaces(). With my recent changes, that's
> become very obvious - the BSD code base has been reduced to a simple
> for loop.
does BSD has ipsec only interface? if yes would that be selected by addconn?
>
> - iface_udp.c:
>
> - #ifdef SOL_UDP - "The SOL (aka socket level) is really the the
> protocol number which, for UDP, is always 17. Linux provides a SOL_*
> macro, the others don't." - since IPPROTO_UDP is defined, why bother?
> - #ifdef SO_PRIORITY - arguably this should live in kernel_linux(?)
> but honestly there's only one use and anyone reading code like this
> expects this stuff
> - its got #ifdef linux - it should probably test for the feature
> - its got kernel_ops. - to poke holes in the NETKEY stack so looks reasonable
>
> and then of course there's the MSG_ERRQUEUE stuff - again it could
> live in *_linux, but to what benefit - at least it is currently local
> ...
More information about the Swan-dev
mailing list