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/.
Max msuraev at sysmocom.deI feel an urge to re-iterate few points - see below. N. B: I'm talking about concrete code available in gerrit. On 05.10.2017 13:09, Neels Hofmeyr wrote: > On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote: >> system RNG is properly seeded at boot, getrandom() should not block at >> any later point in the system's lifetime. > What about an attacker firing endless events that cause us to generate new > TMSIs and ends up exhausting the entropy pool? It still won't block. See https://gerrit.osmocom.org/#/c/1526/ > AFAIK that's a real possibility? Not sure either way: the attacker should deplete entropy faster than kernel gathers it. Also, it's irrelevant for RAND_bytes() vs getrandom() discussion: both use the same entropy pool, both will generate "not good enough" random bytes if out of entropy. So the context for this part of the discussion is in: https://gerrit.osmocom.org/#/c/3819/ https://gerrit.osmocom.org/#/c/3820/ https://gerrit.osmocom.org/#/c/3821/ Meaning: what do we do if we don't get "random enough" data? So far we've just logged it and carried on with insecure rand(). Could/should we do better? Should we fail? Should we let user decide via config option? > Would be interesting to run a few tests on how quickly we can end up in entropy > exhaustion. I think it's more of an academic exercise at this point: even if our tests would show that we can't deplete it, it doesn't mean that attacker couldn't come up with better ways. So we should decide what should be done when this happens. So far the decision was to "log and forget". Should we change it? > But if we practically block because of too little entropy No, we don't. See https://gerrit.osmocom.org/#/c/1526/ The patch was initiated by the need to fix licensing issue, so it preserves all the properties of original code: - it does not block - it uses insecure random Since we're touching this part of the code anyway, we might also change the way we treat entropy depletion. But, it's somewhat orthogonal to the use of getrandom(): we can change the way we deal with RAND_bytes() failure in another unrelated patch series. Using getrandom() is not introducing any problems with the random data which are not already there. It also does not fix any of them. It's good that discussion around it attracted our attention to those problems but I think we should keep in mind that those are related but different issues. -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte