random netbsd 10 update finally supporting getrandom syscall properly. #10327
Conversation
|
I feel like the CSPRNG implementation is slowly turning into a giant ball of mud. #8984 migrated Linux+glibc to arc4random to possibly save on syscall overhead, now this PR effectively does the same in reverse for NetBSD, resulting in the already huge ifdefs becoming even larger. Then for all the Unices except for macOS there is a fallback to /dev/urandom if the main implementation is fallible (i.e. getrandom, not arc4random). Is there some reliable source on the preferred choice for each operating system, so that the implementation can be cleaned up, allowing it to be properly documented as well? https://github.com/php/doc-en/blob/9244ee3baa2dec4b68fde272c22f09a2b05a8fdd/language-snippets.ent#L3767-L3800 is completely outdated by now. |
|
it is indeed a bit messy :-) but for the netbsd case in the hope to remove altogether the older version part at some point. |
ext/random/random.c
Outdated
| * Being a syscall, implemented in the kernel, getrandom offers higher performance | ||
| * compared to the arc4random api albeit a fallback to /dev/urandom is considered. |
There was a problem hiding this comment.
Is this actually true? My understanding is that a syscall is generally slower than a userland function call, due to the necessary context switch. It should be more secure, though.
In any case it certainly contradicts the intent of #8984, which specifically switched to arc4random_buf() for glibc in an attempt to improve performance (which ultimately didn't actually do anything, because glibc's final implementation to my understanding is just a thin wrapper around getrandom(2)).
Note that for the CSPRNG I would generally favor security over speed, it should be plenty fast for almost any use case anyway, so I'm inclined to take this change that switches NetBSD to the syscall and to revert #8984 to unify all the Unices to getrandom (if available).
There was a problem hiding this comment.
ah you re right 🤦🏻♂️ thanks for pointing out, indeed even with VDSO it s not faster.
devnexen
force-pushed
the
random_netbsd_upd
branch
from
2f8a02e to
98881f3
Compare
This effectively reverts php#8984. As discussed in php#10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves. Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.
devnexen
force-pushed
the
random_netbsd_upd
branch
from
98881f3 to
5ca6628
Compare
This effectively reverts #8984. As discussed in #10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves. Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.
| /* Linux getrandom(2) syscall or FreeBSD/DragonFlyBSD/NetBSD getrandom(2) function | ||
| * Being a syscall, implemented in the kernel, getrandom offers higher quality output | ||
| * compared to the arc4random api albeit a fallback to /dev/urandom is considered. | ||
| * Keep reading until we get enough entropy |
There was a problem hiding this comment.
| * Keep reading until we get enough entropy |
This part of the comment is no value-add.
No description provided.