odhcpd: improve odhcpd_urandom()#285
Conversation
|
@systemcrash and @Noltari |
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. |
Yes and no...it uses the same source of randomness (the
Yeah, the quality of the random data is not improved at all by this patch :) |
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>
958b34e to
e1e6060
Compare
|
Merged, thanks @Alphix! |
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.