[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgirNWqk6d4y/Z0k@owl.dominikbrodowski.net>
Date: Sun, 13 Feb 2022 07:54:45 +0100
From: Dominik Brodowski <linux@...inikbrodowski.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v2 07/10] random: group entropy collection functions
> + * add_device_randomness() adds data to the input pool that
> + * is likely to differ between two devices (or possibly even per boot).
> + * This would be things like MAC addresses or serial numbers, or the
> + * read-out of the RTC. This does *not* credit any actual entropy to
> + * the pool, but it initializes the pool to different values for devices
> + * that might otherwise be identical and have very little entropy
> + * available to them (particularly common in the embedded world).
> + *
> + * add_input_randomness() uses the input layer interrupt timing, as well
> + * as the event type information from the hardware.
> + *
> + * add_disk_randomness() uses what amounts to the seek time of block
> + * layer request events, on a per-disk_devt basis, as input to the
> + * entropy pool. Note that high-speed solid state drives with very low
> + * seek times do not make for good sources of entropy, as their seek
> + * times are usually fairly consistent.
> + *
> + * The above three routines try to estimate how many bits of entropy
*two* (add_device_randomness() does not credit any entropy).
Thanks,
Dominik
Powered by blists - more mailing lists