[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