Contributions to netifd

[Joerg Vehlow]

Hi,

sorry for the long response time

Am 8/3/2022 um 11:00 AM schrieb 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.
I took a look a the cmake file for several projects (ubus, uci, netifd,
...) and found that they are quite outdated and not modern cmake at all.
I wonder if there ever was an approach, to modernize them, e.g. using
export and import targets for the libraries instead of manually
searching for include and library files and library dependency
management (public interfaces) and not the non target_*-family of functions.

>>  - 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

Is this already possible with ucode? I took a brief look at the
repository and did not see anything in that direction. I guess as long
as the VM is able to load the bytecode from any location it would still
violate the security concept.

> 
>>  - 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.
Maybe. If we select a plugin approach, both solutions could coexist.

>>  - 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?

I am not sure at the moment, this is postponed because of the
complexity. Maybe static nftables and tc would be enough for the
foreseeable future, without a lot of support from netifd required.

> 
>>  - 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.
Coming back to my question above: "theoretically" means, it is not yet
implemented, right? ucode is your project, if I am not mistaken, so
chances are good, that this is feasible :)

> 
>>> 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.

I am not sure about dlopen, but if the buildsystem allows hooking into
it easily, I see no problem, to add "plugins" during the build process.
They are registered loaded using __init-sections anyway, so they can be
compiled standalone and have to be linked with netifd. Otoh
dlloaded-plugins would allow packaging of plugins independent of netifd
and allow customization during installation/configuration, e.g. swapping
of dhcp proto implementation and deactivation of proto-script.

>> 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.

Actually the idea is not implementing a whole new dhcp client, but just
replacing the shell script parts with c code. I did a PoC using isc's
dhclient already (implementing a proto-dhcp inside netifd and a
standalone binary, that is used as the dhcp script, that calls back into
netifd using the notify mechanism) and just struggle a bit with
semantics inside of netifd. I might come back with some questions here.
(Biggest problem was ipv6 dad for the link local, that must be
completed, before dhclient PREINIT6 hook can return. I implemented that
in the "script"-binary using netlink, because I think it cannot be
handled in netifd, because blocking in the notify-handler is probably a
very bad idea.)

Joerg