Philippe Houdoin wrote:
But that makes the DHCP code vulnerable to buffer overflow attacks.
Like pretty much all our code. That's not specific to DHCP. And not even specific to kernelland.
It still an issue we must take care off, but I don't see why it matter for DHCP protocol more than every others...
No, I meant putting code into the kernel gives attackers the possibility to get full system access (on multi-user OSes) whereas dhcp_client could run in a sandbox with very limited FS&system access (if we support this in R2+).
I mean, if speed were an issue I would do it, but I cannot imagine any good reason to use that.
Simplicity?
It's a protocol and a network feature, considered as de-facto today.
ZeroConf would be in short time considered a de-facto feature, and it needs a tigh DHCP and DNS support integration into the stack to works fine.
It's a simple feature, too.
And it's very similar to BOOTP, which should work in a very limited operating system environment (not userland space, for example).
A crash in the kernel is very critical. If we move code from kernel to userland we lower the risk of a full system crash. I do not know very much about DHCP and how big it is, so maybe it does not harm putting it into the kernel (if it really is small) as bugs are rather unlikely. ZeroConf can use the kernel module as if it were part of the stack, I do not see any problem with DHCP not being integrated enough.
It doesn't mean we don't need a userland tool to turn on or off an interface DHCP mode, because we still needs one.
It mean splitting DHCP "protocol" handling into parts (dhcp_client handling discovery and setup, stack module waking up dhcp_client on lease expiration) doesn't bring us any benefit. Or am I blind?
> [...]
I prefer having a module (exporting the main API) interacting with a userland tool (exporting a private API for the module) just for the stability and security reasons explained above.
Bye, Waldemar
