Am Samstag, 25. Mai 2019, 12:43:25 CEST schrieb Etienne Champetier: Hi Etienne,
> Hi Petr, > > Just to be clear i'm 100% in favor of your effort to have random pool > init done fast on all devices, > and your solution, based on Stephan awsome work, seems really good > I just want to be sure we don't make some devices worse / are not > missing something > > Le mar. 21 mai 2019 à 16:55, Petr Štetiar <yn...@true.cz> a écrit : > > Etienne Champetier <champetier.etie...@gmail.com> [2019-05-21 14:55:42]: > > > > Hi, > > > > > > First, simply writing to /dev/urandom does not increase the kernel's > > > > entropy count, this casuses processes obtaining randomness to block. > > > > Particularly processes using OpenSSL's RAND_bytes() will block until > > > > the > > > > kernel emits 'random: crng init done'. This can take upwards of twenty > > > > minutes. > > > > > > 20 minutes seems excessive, isn't one of the process blocking boot ? > > > > please note, that this is time as measured by kernel (I know it's > > userspace > > starving the kernel entropy pool, but still). I've personally measured 18 > > minutes on my Apalis board (imx6)[1]. > > > > i.mx6 (Freescale i.MX6 Quad/DualLite) > > > > [ 3.281637] random: fast init done > > [ 1120.394672] random: crng init done (yeah, 18 minutes) > > I'm not saying it's not happening, I'm wondering if the boot process > is not blocked early by a process stuck on getrandom() > and then nothing runs on router so no entropy is produced, so the > process continue to be stuck Well, some libraries still use /dev/urandom and are not blocked. Besides, if you use systemd that initializes the system, it uses /dev/urandom. Compile your kernels with CONFIG_WARN_ALL_UNSEEDED_RANDOM, you will see kernel reports which processes seed from /dev/urandom even while it is not fully provided with entropy. > > > > One of the issue is that if you try to generate a new seed, you are > > > just reading a hash of the seed you injected seconds earlier with > > > maybe few new bits of entropy > > > > Exactly, that's why it's recommended[2] to save it during EVERY shutdown, > > so it's different EVERY boot. > > I know and I'm in favour of it, but proper shutdown is not always a > thing on router, that is why I went with getrandom() at the time > > > * Ensuring unpredictability at system startup > > * ============================================ > > * > > * When any operating system starts up, it will go through a sequence > > * of actions that are fairly predictable by an adversary, especially > > * if the start-up does not involve interaction with a human operator. > > * This reduces the actual number of bits of unpredictability in the > > * entropy pool below the value in entropy_count. In order to > > * counteract this effect, it helps to carry information in the > > * entropy pool across shut-downs and start-ups. > > > > [...] > > > > * Even with complete knowledge of the start-up activities, predicting the > > * state of the entropy pool requires knowledge of the previous history of > > the * system. > > > > We're making it easier for the potential adversary, aren't we? We're > > currently feeding static urandom.seed file (generated during first boot) > > to kernel every other boot, in some cases it might result in the same > > file for the lifetime of the device. I really miss any randomness in > > this. > > Starting on second boot, we are sure each router state is different, > but each boot are pretty similar I agree > > > > Just for the record, this is the default setting, > > > > I know, that's why I'm proposing removal from the default ath79 images, > > because I think, that it's wrong. Should the user ever need urandom-seed, > > then it's just one opkg install away. > > > > > you can change your config to generate a new one at each boot > > > > I know, but who does it? I expect best possible secure configuration by > > default. > > > > > (the worry was that we would wear off the flash too fast) > > > > I understand the drawbacks, that's why I think, that it doesn't make much > > sense to use it, if it's not good enough to be used in default/shipped > > configuration. > > > > > why not use jitterentropy RNG that is in kernel since 4.2 ? > > > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4db > > > fa4520013> > > I started experiments with kmod-crypto-rng package which already contains > > jitterentropy, drbg, krng and rng kernel modules, but it didn't improved > > the long booting times for me on ath79. Other reason was size of this > > kernel module(s) as they provide much more functionality of course. > > I think before anyone merge this (I'm not a core dev), we need to > explain why your user space version and the kernel module version > behave differently > Is the kernel module underestimating entropy ? Is you user space > version over estimating entropy ? Again, the in kernel version is *only* used for seeding the in-kernel DRBG (unfortunately). This DRBG and the in-kernel Jitter RNG has no relationship with /dev/random or /dev/urandom or getrandom. You could call the in-kernel DRBG with AF_ALG like libkcapi allows you to do [1]. If you are interested, I wrote a complete replacement implementation of the current /dev/random or /dev/urandom available at [2]. It uses the in-kernel Jitter RNG, it has pluggable PRNGs and other logic relevant for, say, FIPS 140-2. This implementation would not require you to have your separate user space entropy daemon that is discussed here. Yet, this code was rejected. [1] http://www.chronox.de/libkcapi.html [2] http://www.chronox.de/lrng.html Ciao Stephan _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
