On 2017-10-06 12:50, Max wrote:
On 06.10.2017 03:23, Harald Welte wrote:
So the conclusion is probably, for now:
- use getrandom() with zero flags for TMSIs and other random identifiers
- use getrandom() with zero flags for RAND challenges
I don't think it's a good idea. It's fine for exploratory programming while experimenting but in the library which is meant for production use behavior should be as predictable as possible.
Using "zero flags" means that the function might or might not block which pretty-much guarantees headaches later on when troubleshooting the code which will use it.
Is there any reason that it isn't just called a single time on system startup? It should never again block after that point in time. A measurement that might be worth considering is if it blocks, ever, in practice? At least one of my Debian systems appears to ensure that the RNG is seeded before it has reached the run level where services run. Might that be the case here? Might it also be possible to call the wrapper for getrandom() at library init time as well as later when the random bytes are needed?
I think we should always opt for "least surprise" path and use GRND_NONBLOCK (as in current patch). That way we'll never block and let the caller handle errors (if any).
Isn't it more error prone to handle errors and unfilled buffers than to block a single time? Seems tricky, though I agree that consistent behavior might be worth the trade off. If GRND_NONBLOCK ensures that no buffer is ever underfilled, that might be the middle ground that makes the most sense.
- use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both /dev/random and /dev/urandom are going through the same CSPRNG so I'm not sure we gain anything by requiring random instead of urandom.
That is my understanding as well. The key difference is that you were spot on about the pool being drained very seriously - to the point of underflowing, thus potentially encountering serious error states. Those error states might be a 512 byte buffer with only one random byte, for example.
Happy Hacking, RS