Hey Jason, Le lun. 28 mars 2022 à 13:04, Jason A. Donenfeld <ja...@zx2c4.com> a écrit : > > Hey Etienne, > > On Mon, Mar 28, 2022 at 10:19 AM Etienne Champetier > <champetier.etie...@gmail.com> wrote: > > > > Hi All, Jason, > > > > @Petr Štetiar this merge was a bit too fast to get reviews ... > > Some comments inline > > We can apply fixups on top, no big deal. > > > When urandom-seed was introduced in 2016 it was decided during review > > that writing on each boot might cause too much wear to the flash. > > Maybe we can say that 6 years later this is not a problem anymore, but > > would love to have more devs comment > > Old thread: > > https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01225.html > > > > Now if I understand correctly, with this patch we are writing a seed > > to flash twice per boot, in preinit/81_urandom_seed and in > > init.d/urandom_seed. > > Also there are good chances we will never have a seed.credit at all on > > many devices, > > would be great if seedrng had an option "writeseed" that blocks on > > getrandom(). > > Oh that's an interesting set of considerations and it's possible I > didn't understand some aspect of this. Most OSes should call seedrng > once at boot and once at shutdown.
As routers are always on devices, it's rare to have clean shutdown. Personally, my routers boot after an upgrade or after a power loss, so they almost never shutdown properly. > It's also fine to call seedrng at > any other specific time during runtime too. Because it's involved with > crediting, it always always removes the seed file after reading but > before using, and after it's used, it immediately writes a new seed > file. > > It sounds like what you might want here is, perhaps, the original > behavior? Namely, the seed is never credited, but it never changes > either? That won't help you initialize the RNG, but since you're not > crediting it, you can argue that all new rng inputs are good inputs, > even if they've been used before. > > So these are the two schemes to choose from: > > 1) read seed into memory, delete seed from disk, write into rng & > credit if good seed, write new seed to disk; repeat at shutdown/some > other time > 2) read seed into memory, write into rng w/o crediting, re-use the > same seed next boot Before this patch we had 2 and users could opt-in to renew seed on each boot, so closer to 1. > If the second scheme is what you prefer, then your original bug report > suggesting this was an issue for OpenWRT might not really be so, and > we can just go back to what we were doing before. OTOH, if you want to > have a good mechanism that actually initializes the RNG, perhaps we > can move forward with some tweaks to seedrng. Looking at random.c, I would love add_device_randomness() behavior. Maybe it was already answered on LKML, but why can't writes to /dev/urandom from a process with CAP_SYS_ADMIN be mixed in right away a la add_device_randomness() without being credited ? This would not init the RNG faster, but this would make early /dev/urandom reads "safer". I'm fine with writing on each boot, but as we can't rely on shutdown, what we could do with the seeds: 1) load seed.no-credit, leave it on disk 2) mv seed.credit seed.no-credit && load seed.no-credit (and credit it) 3) read from getrandom a new seed.credit This would allow to always keep a seed on disk, only use seed.credit once, and actually write seed.credit. I would get rid of the whole hashing part as all our seeds would come from getrandom(). > > > + > > > +#define SEED_DIR "/etc/seedrng" > > > > If we worry about seed reuse, we should not use /etc as it can be > > restored from a backup > > Indeed you're right. Most other distros use /var/lib/seedrng; is > /var/lib available on OpenWRT? /var is a symlink to /tmp > Is there a different place for it that would be good? Maybe we can leave it in etc and just make sure to exclude it from backups Etienne > > Jason _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
