On Tue, 12 Apr 2022 21:07:36 +0200 "Jason A. Donenfeld" <ja...@zx2c4.com> wrote:
> Hi Bernhard, > > On Tue, Apr 12, 2022 at 8:37 PM Bernhard Reutner-Fischer > <rep.dot....@gmail.com> wrote: > > > > Hi Jason! > > I'm a bit surprised that even if i give -n the seed is moved to > > seed.credit. The next boot/run will find the now creditable seed and > > happily add it, IIUC, despite i wanted it to not be credited? > > Is this intentional? > > Yes. You misunderstand the purpose of the utility. It creates a > creditable seed when the kernel is able to produce safe random > numbers. In that case, the creditability or non-creditability of the > previous seed does not matter. So to go back to the underlying issue. In v8 we cannot guarantee that we really got a seed from the kernel, let alone trustworthy. It could have been data from about any file, including /dev/zero or other unhelpful, no-random data. I think that adding and crediting a block of 0 is not what we want. Ignoring interference from other processes with CAP_SYS_ADMIN, to somewhat tighten this up, we'd need to open /dev/random once and do our stuff with this rnd_fd, including an fstat to ensure we are really reading from the random character device 1,8 or chardev 1,9 for urandom. [Can we ioctl on urandom to RNDADDENTROPY to the pool btw? ah yes, we can; only read is different in fops. That's handy and simplifies the flow.] > > > > PPS: I'm attaching some fiddle on top of your v8 which would give a > > relative savings of > > I'm not _super_ comfortable with all of these, and I don't know if I > feel good about attaching them to the original commit. At this Sure. If we want a robust implementation then IMO we'd need to bite the bullet and trade some size penalty for an implementation that works reliably. The bar for x86_64 with gcc-12 and aforementioned additional fiddle was circa $ size util-linux/seedrng.o* text data bss dec hex filename 1658 0 0 1658 67a util-linux/seedrng.o I guess we should get away with an estimated additional 150 bytes of robustification, maybe even a tiny bit less than that. > late-stage of golfing, we really risk introducing excessively brittle > code and bringing along new bugs with it. These additional strokes > need to be considered very carefully and individually. So I think at > this point, I'm done on the green, and I think what you ought to do is > commit my v8, and then send your patches as a series, and I'll take > the time to look very carefully at each one individually and comment > on them. And by keeping those as separate commits, if we both do miss > something, it'll be easier to revert and for others to notice the > error too. Does that plan sound okay to you? Commit v8, and then tee > off a new golfing series? I think that we want to manually inline seed_from_file_if_exists anyway. And that loop was about the only ugly thing, from a cosmetic POV. Care to send an updated patch? Feel free to incorporate any of the additional size-tweaks as you see fit. thanks and cheers, _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox