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-05 13:17, Max wrote: > On 05.10.2017 14:40, ringsignature at riseup.net wrote: >> >> As I understand the getrandom() interface in modern Linux systems - it >> is documented to block until it is initialized and then never block >> again - is that an incorrect understanding of that interface? > > More like incomplete. We use it with *GRND_NONBLOCK parameter to make > sure it never > blocks.* OK. If it is called at startup a single time without that parameter, all subsequent calls should be completely non-blocking and the interface promises to provide CSPRNG quality random bits. This is strictly an improvement over rand() and when getrandom() isn't available on a system, extra work will be required. Are there any such systems? > >> >> Additionally, it would be good to ensure that any >> system running OpenBSC has some source of entropy beyond interrupts and >> timing - is that already the case? > > Out of curiosity - is there a way to check for this programmatically? It is possible to check for the presence of some devices by checking CPU flags (RDRAND, etc). In theory, a call to getrandom() with no flags set should also tell you if the system itself thinks if it has entropy. If the call doesn't block, there is something generating data that the system considers to be entropy. >> >> Is there a system wide entropy depletion monitor in place? > > Not that I know of. Is it some sort of a program or some kernel sysctl knob? There is an entry in /proc which provides an estimate: /proc/sys/kernel/random/entropy_avail I wrote a small benchmark in C to use getrandom() to fetch random bytes using the SYS_getrandom system call. The entropy_avail value fluctuated between 3820 and 3830 consistently. It doesn't seem that fetching many hundreds of megabytes of random data impacted the system's PRNG entropy pool estimation. This seems to be what is expected: the original entropy is expanded by the PRNG and reading the output of the PRNG does not exhaust the pool with a 1:1 ratio. Happy Hacking, RS