[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#29725] [PATCH 2/2] services: urandom-seed: Try using a HWRNG to see
[bug#29725] [PATCH 2/2] services: urandom-seed: Try using a HWRNG to seed the Linux CRNG at boot.
Mon, 18 Dec 2017 09:06:25 +0100
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Leo Famulari <address@hidden> skribis:
> On Sun, Dec 17, 2017 at 04:31:27PM +0100, Ludovic Courtès wrote:
>> Leo Famulari <address@hidden> skribis:
>> If we fail to read from /dev/hwrng we may end up writing zeros to
>> /dev/urandom (because ‘buf’ is left uninitialized).
> Right, the patch I sent wrote the buffer to urandom unconditionally.
> It's sloppy when the buffer is uninitialized but does no harm to the
>> To address that, perhaps this could be formulated like this:
>> (let ((buf (catch 'system-error
>> (lambda ()
>> (call-with-input-file "/dev/hwrng"
>> (lambda (port)
>> (get-bytevector-n port 512))))
>> (const #f))))
>> (when buf
>> (call-with-output-file "/dev/urandom"
>> (lambda (urandom)
>> (put-bytevector urandom buf)))))
> Overall I like this better.
> I tested it and catching system-error seems to work for the case when
> /dev/hwrng exists but there is nothing actually there.
> I noticed you used get-bytevector-n instead of get-bytevector-n!. The
> documentation says that the former reads "octets" while the latter reads
> "bytes" . I guess there is no difference in practice in 2017, right?
There was also no different in 1970 I think. ;-) “Octet” is just
slightly more precise, I guess.
>> This also removes the need for the ‘file-exists?’ call.
> I don't know what creates /dev/hwrng or under what conditions. I didn't
> see it in (gnu build linux-boot). Can we rely on it to exist for all the
> versions of Linux we support?
I guess it’s created by udev, I don’t know exactly under what
circumstances. I have it on my GuixSD laptop, even though it doesn’t
have a hardware RNG.