Skip to content

odhcpd: improve odhcpd_urandom()#285

Merged
openwrt-bot merged 1 commit intoopenwrt:masterfrom
Alphix:better_random
Oct 22, 2025
Merged

odhcpd: improve odhcpd_urandom()#285
openwrt-bot merged 1 commit intoopenwrt:masterfrom
Alphix:better_random

Conversation

@Alphix
Copy link
Contributor

@Alphix Alphix commented Oct 21, 2025

First, note that not a single caller checks the return value - which is quite reasonable. What are they supposed to do with a failure?

Second, none of the callers do anything that's really security-sensitive, the closest we have is the force reconf nonce, and that is blorted out over the network, so it's really a best-effort kind of thing.

Third, odhcpd_urandom() currently doesn't check if it e.g. got interrupted by a signal.

So, simplify and modernize this a bit by using getrandom(), which allows us to skip one fd, and which avoids syscalls by using the vDSO approach instead. Also, check for things like signal interrupts (don't really happen on calls for entropy < 256 bytes, but still). And make a reasonable effort, but not much more.

@Alphix
Copy link
Contributor Author

Alphix commented Oct 21, 2025

@systemcrash and @Noltari

@systemcrash
Copy link
Contributor

by using getrandom(), which allows us to skip one fd

Aren't we just kicking the can down the road here? getrandom() reads from /dev/urandom ya?

Just an idea - given that odhcpd and odhcp6c can be thought of as client/server team here, and that new patchset for odhcp6c provides support for RKAP, which also uses HMAC-MD5, I guess we're no worse off.

If we're not striving for high quality randomness, DHCP is the last place we should worry about if the NSA is attempting to gain access to our system :D

Bottom line: OK by me.

@Alphix
Copy link
Contributor Author

Alphix commented Oct 21, 2025

by using getrandom(), which allows us to skip one fd

Aren't we just kicking the can down the road here? getrandom() reads from /dev/urandom ya?

Yes and no...it uses the same source of randomness (the urandom pool), but it gets the random bytes from the pool using the vDSO mechanism, which avoids both syscalls and file descriptors (meaning it uses less CPU cycles and is also oblivious to things like being chroot():ed, etc). It also handles EINTR better (reads < 256 bytes are guaranteed to not be interrupted...which is all the calls we currently do).

If we're not striving for high quality randomness, DHCP is the last place we should worry about if the NSA is attempting to gain access to our system :D

Yeah, the quality of the random data is not improved at all by this patch :)

@Noltari Noltari self-assigned this Oct 22, 2025
First, note that not a single caller checks the return value - which is
quite reasonable. What are they supposed to do with a failure?

Second, none of the callers do anything that's *really*
security-sensitive, the closest we have is the force reconf nonce, and
that is blorted out over the network, so it's really a best-effort kind
of thing.

Third, odhcpd_urandom() currently doesn't check if it e.g. got
interrupted by a signal.

So, simplify and modernize this a bit by using getrandom(), which allows
us to skip one fd, and which avoids syscalls by using the vDSO approach
instead. Also, check for things like signal interrupts (don't really
happen on calls for entropy < 256 bytes, but still). And make a
reasonable effort, but not much more.

Signed-off-by: David Härdeman <david@hardeman.nu>
Link: openwrt#285
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
@openwrt-bot openwrt-bot merged commit e1e6060 into openwrt:master Oct 22, 2025
5 checks passed
@Noltari
Copy link
Member

Noltari commented Oct 22, 2025

Merged, thanks @Alphix!

@Alphix Alphix deleted the better_random branch October 22, 2025 07:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants