On Sat, Aug 15, 2020 at 06:49:11PM +0000, Taylor R Campbell wrote: > - The behaviour is incompatible only in the sense that NetBSD's idea > of `adequate entropy' is stronger than FreeBSD's or Linux's, so > blocking is _more likely_ on NetBSD than on FreeBSD or Linux.
In practice, the blocking being more harsh is surprising to the typical user. Other operating systems simply don't agree with NetBSD's unblocking criteria. As an application author, I'd consider the difference between unblocking automatically after recieving some idle network packages and only unblocking with user intervention to be an API difference. > If FreeBSD makes _more_ promises, fine, but the GRND_RANDOM flag a > silly API that exists only for Linux source compatibility that very > few reasonable applications use. So I don't see why it's important to > put any attention on it or make any stronger promises about it than > portable applications can rely on -- that's why, e.g., the man page I > wrote specifically calls it out as silly, not recommended, for Linux > source compatibility only, and with no usage examples. Why does there need to be a specific code path for handling something that's "silly, not recommended", and not even standardized? If something's there, then someone with inevitably end up using it at some point. Keep the define, just make it do nothing. If it's not supposed to be used, how will it be tested? Just remove it and reduce potential for harm. > The Rust API specifically describes getrandom(p,n,0) semantics: > > https://docs.rs/rand/0.7.3/rand/rngs/struct.OsRng.html > > `It is possible that when used during early boot the first call to > OsRng will block until the system's RNG is initialised. It is also > possible (though highly unlikely) for OsRng to fail on some > platforms, most likely due to system mis-configuration. Key word here being "possible". It's entirely valid for us to decide that any entropy consolidated before userland is "good enough", and initialize with that. We don't need to implement a Linux system call just because Rust documentation provides a vague hint that an OS _may_ implement that specific Linux syscall's semantics. > Obviously we can patch OpenSSL in base however we like, but at least > one OpenSSL developer reported being uncomfortable with having > getrandom(p,n,GNRD_INSECURE) semantics for getentropy if used > upstream: > > https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012334.html > > `If you make getentropy the insecure version, I will need to modify > OpenSSL to switch to getrandom() on NetBSD.' We then had a long discussion about entropy (which is arguably not on-topic). But, key point: I'm not sure why he considers OpenBSD's implementation to be safe without blocking and NetBSD's to be unsafe. Marketing, I suspect. In practice, OpenSSL uses entirely non-blocking APIs on both.