This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
ringsignature at riseup.net ringsignature at riseup.netOn 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