Contributions to netifd

[Jo-Philipp Wich]

Hi Joerg,


> we are a company of experts for automotive software and are working for
> many customers in the automotive industry.
> 
> One of our customers (a big german automotive supplier) is looking for a
> network configuration solution with some specific limitations and after
> evaluating several alternatives (e.g. network manager, wicked, ...) we
> ended up with netfid being the best solution giving the requirements.

That sounds really awesome!

> However netifd does not (yet) fully fit the requirements and instead of
> developing a fork, our customer would like to contribute to OpenWRT
> directly and integrate required features/changes.

I am really happy to hear that, and it's certainly the correct approach imho.

> Some examples of what we know at the moment what would be needed:
>  - We may need static linking of the libraries used in netifd. I saw
> that this is basically possible, but a bit broken IIRC.

It is entirely possible that this is broken, at least it is not something that
is frequently tested (or tested at all). But I don't foresee any big issues in
solving that.

>  - One of the requirement (For security reasons) is, that the system
> should be able to run without a script interpreter (not even a shell),
> but we need dhcp. So one of the first proposals would be creating a dhcp
> protocol implementation in c

Is the security policy also prohibiting embedded VMs that execute precompiled,
immutable byte code? Using ucode would allow for this and implementing the
higher level proto handling in it vastly simplifies things

>  - VPN configuration (possible ipsec with strongswan) will be required
> and we would also need to implement this directly in c.

That is a lot of complexity / a huge amount of code you're going to implement
in C there, and it's mostly going to lie dormant upstream I suppose, since
OpenWrt will likely stick to the existing external solutions integrated via
scripting.

>  - As far as I can see, there is no tooling for QoS/tc in openwrt at the
> moment. This is probably also required and could be implemented as part
> of netifd.

There's SQM scripts and the like. Or do you refer to QoS/tc integration
directly in netifd?

>  - Traffic filtering is one more point on our list of requirements. I
> know that you use fw3 and I saw fw4 for nftables. However I guess fw4
> will not work for us, because of ucode, but I could be wrong here.

Same question as above. Theoretically the entire fw4 ucode sources could be
precompiled into a single bytecode image which you could then embed into an
ELF executable providing the ucode VM. The end result would also be a compiled
executable running its own code and not externally modifiable source files.

> > I guess most of the changes could also help the OpenWRT community. If
> some of the changes are not really what you want for OpenWRT users, we
> could also think about implementing a plugin API, much like the proto
> handler API, but without additional exec-calls.

That definitely makes sense. However to be usable in practice for the kind of
use-cases OpenWrt aims for, that plugin API would need to rely on dlopen() to
be able to load plugins at runtime, I guess that would violate your security
architecture constraints, right?

Obviously it could be made a compile time option to build-in modules directly
in the executable - it's just something we should have in mind when designaing
an implementation.

> Would these kind of contributions be wanted by OpenWRT?

I can not speak for the others, but personally I do think that (at least some
of) the proposals are useful and I'd love to help.

I am a bit wary of doing a custom DHCP implementation, Busybox udhcpc for
example is quite old already and there's still issues being discovered with it
nowadays. I guess such a custom implementation would require a lot of time to
mature. On the other hand it's probably going to run in a very controlled
environment so it might not be as problematic after all.


Kind regards,
Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20220803/7cd0e774/attachment.sig>