4 ms·
It's such a ridiculous API. What's the point of documenting a guarantee if there's officially speaking no guarantee? When I implemented getentropy() for cosmo l
by jart 2y ago
It's such a ridiculous API. What's the point of documenting a guarantee if there's officially speaking no guarantee? When I implemented getentropy() for cosmo libc, it'll actually issue three system calls in the best case on Linux to block signals while calling getrandom() because I've never trusted it.
But I still refuse to believe it's possible for a PRNG to block in a way where there's observable side-effects like EINTR. It's just too insane. There's no Linux architecture that does this when flags==0 && size<=256 and there never will be one, because that's a bug. Prove that it can happen and we shall patch the kernel to make it not happen.
- monocasa 2y agoI mean, if there isn't enough entropy yet to seed the kernel's PRNG (because say, you just resumed a VM image, and all entropy pools are invalidated), and you didn't specify that it's allowed to fail becuase you didn't specify non block, what is it supposed to do other than block and allow signals and thus potentially fail with EINTR? I fail to see the bug here.
- deleted 2y ago[deleted]
- jart 2y agoDon't bring processes back to life until the kernel prng is seeded?
- monocasa 2y agoWhy would you cut into an operation that's already measured milliseconds (vm image rehydration is one of the implementations of 'serverless') over a single syscall that's already built around the idea of blocking if it needs more time?