LinuxLists.cc - [PATCH] hw_random: treat default_quality as a maximum and default to 1024

2022-11-04 15:56:40

Subject: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

2022-11-06 07:10:16

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

Am Fri, Nov 04, 2022 at 04:42:30PM +0100 schrieb Jason A. Donenfeld:
> Most hw_random devices return entropy which is assumed to be of full
> quality, but driver authors don't bother setting the quality knob. Some
> hw_random devices return less than full quality entropy, and then driver
> authors set the quality knob. Therefore, the entropy crediting should be
> opt-out rather than opt-in per-driver, to reflect the actual reality on
> the ground.
>
> For example, the two Raspberry Pi RNG drivers produce full entropy
> randomness, and both EDK2 and U-Boot's drivers for these treat them as
> such. The result is that EFI then uses these numbers and passes the to
> Linux, and Linux credits them as boot, thereby initializing the RNG.
> Yet, in Linux, the quality knob was never set to anything, and so on the
> chance that Linux is booted without EFI, nothing is ever credited.
> That's annoying.
>
> The same pattern appears to repeat itself throughout various drivers. In
> fact, very very few drivers have bothered setting quality=1024.
>
> So let's invert this logic. A hw_random struct's quality knob now
> controls the maximum quality a driver can produce, or 0 to specify 1024.
> Then, the module-wide switch called "default_quality" is changed to
> represent the maximum quality of any driver. By default it's 1024, and
> the quality of any particular driver is then given by:
>
> min(default_quality, rng->quality ?: 1024);
>
> This way, the user can still turn this off for weird reasons, yet we get
> proper crediting for relevant RNGs.

Hm. Wouldn't we need to verify that 1024 is appropriate for all drivers
where the quality currently is not set?

Thanks,
Dominik

2022-11-06 14:46:35

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

Hi Dominik,

On Sun, Nov 06, 2022 at 08:05:25AM +0100, Dominik Brodowski wrote:
> Am Fri, Nov 04, 2022 at 04:42:30PM +0100 schrieb Jason A. Donenfeld:
> > Most hw_random devices return entropy which is assumed to be of full
> > quality, but driver authors don't bother setting the quality knob. Some
> > hw_random devices return less than full quality entropy, and then driver
> > authors set the quality knob. Therefore, the entropy crediting should be
> > opt-out rather than opt-in per-driver, to reflect the actual reality on
> > the ground.
> >
> > For example, the two Raspberry Pi RNG drivers produce full entropy
> > randomness, and both EDK2 and U-Boot's drivers for these treat them as
> > such. The result is that EFI then uses these numbers and passes the to
> > Linux, and Linux credits them as boot, thereby initializing the RNG.
> > Yet, in Linux, the quality knob was never set to anything, and so on the
> > chance that Linux is booted without EFI, nothing is ever credited.
> > That's annoying.
> >
> > The same pattern appears to repeat itself throughout various drivers. In
> > fact, very very few drivers have bothered setting quality=1024.
> >
> > So let's invert this logic. A hw_random struct's quality knob now
> > controls the maximum quality a driver can produce, or 0 to specify 1024.
> > Then, the module-wide switch called "default_quality" is changed to
> > represent the maximum quality of any driver. By default it's 1024, and
> > the quality of any particular driver is then given by:
> >
> > min(default_quality, rng->quality ?: 1024);
> >
> > This way, the user can still turn this off for weird reasons, yet we get
> > proper crediting for relevant RNGs.
>
> Hm. Wouldn't we need to verify that 1024 is appropriate for all drivers
> where the quality currently is not set?

No, certainly not, and I think this sort of thought belies a really
backwards attitude. Hardware RNGs are assumed to produce good
randomness. Some manufacturers provide a caveat, "actually, we're giving
raw entropy with only N bits quality", but for the ones who don't, the
overarching assumption is that the bits are fully entropic. This is
what's done every place else in the field, across operating systems,
boot environments, firmwares, and otherwise. It's so much so, that both
EDK2's EFI and U-Boot's DTB and U-Boot's EFI will use RNGs for which the
Linux driver has an empty quality setting and provide output from these
as fully entropic seeds to Linux. And why shouldn't they? It seems
entirely reasonable to do, given very okay assumptions.

But more generally, this fetishization of entropy estimation has got to
come to a close at some point. It wasn't a very good idea in the first
place to bake that into the heart of all the Linux RNG APIs, but here we
are. Just consider how meaningless the count is: random.c will do some
completely bogus hocus pocus with interrupt counting, with disk seeks,
with input events, to draw a number out of hat. Or it will twiddle
around with `struct timer_list` functions and count some entropy there,
which is complete nonsense, but whatever, it's by and large "good
enough". However, what we're talking about here are RNG hardware devices
that say on the tin "hey I'm an RNG device", which is an infinitely
better guarantee that we should count entropy from them (unless, of
course, the tin also says, "only count half the bits", or whatever).

I mention "good enough", because really, the more important thing here
from the security angle is that we're getting bits into the RNG quite
fast at boot, and we largely accomplish that now. The next important
thing is getting the RNG initialized quickly so that userspace doesn't
block. Adding hw_random to the equation makes perfect sense here.

And, like RDRAND, there's still a switch to turn this off for lunatics
who simply don't trust anything.

So, no, the way hw_random is oriented now, the whole thing is backwards,
in a way that's not reflected across the rest of the hardware RNG and OS
ecosystem, and just results in a total waste. I think it's important
that we don't hold up progress here.

Jason

2022-11-07 07:41:19

by Dominik Brodowski

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

Hi Jason,

Am Sun, Nov 06, 2022 at 03:40:44PM +0100 schrieb Jason A. Donenfeld:
> On Sun, Nov 06, 2022 at 08:05:25AM +0100, Dominik Brodowski wrote:
> > Am Fri, Nov 04, 2022 at 04:42:30PM +0100 schrieb Jason A. Donenfeld:
> > > Most hw_random devices return entropy which is assumed to be of full
> > > quality, but driver authors don't bother setting the quality knob. Some
> > > hw_random devices return less than full quality entropy, and then driver
> > > authors set the quality knob. Therefore, the entropy crediting should be
> > > opt-out rather than opt-in per-driver, to reflect the actual reality on
> > > the ground.
> > >
> > > For example, the two Raspberry Pi RNG drivers produce full entropy
> > > randomness, and both EDK2 and U-Boot's drivers for these treat them as
> > > such. The result is that EFI then uses these numbers and passes the to
> > > Linux, and Linux credits them as boot, thereby initializing the RNG.
> > > Yet, in Linux, the quality knob was never set to anything, and so on the
> > > chance that Linux is booted without EFI, nothing is ever credited.
> > > That's annoying.
> > >
> > > The same pattern appears to repeat itself throughout various drivers. In
> > > fact, very very few drivers have bothered setting quality=1024.
> > >
> > > So let's invert this logic. A hw_random struct's quality knob now
> > > controls the maximum quality a driver can produce, or 0 to specify 1024.
> > > Then, the module-wide switch called "default_quality" is changed to
> > > represent the maximum quality of any driver. By default it's 1024, and
> > > the quality of any particular driver is then given by:
> > >
> > > min(default_quality, rng->quality ?: 1024);
> > >
> > > This way, the user can still turn this off for weird reasons, yet we get
> > > proper crediting for relevant RNGs.
> >
> > Hm. Wouldn't we need to verify that 1024 is appropriate for all drivers
> > where the quality currently is not set?
>
> No, certainly not, and I think this sort of thought belies a really
> backwards attitude. Hardware RNGs are assumed to produce good
> randomness. Some manufacturers provide a caveat, "actually, we're giving
> raw entropy with only N bits quality", but for the ones who don't, the
> overarching assumption is that the bits are fully entropic.

My point is not about the 1024 as an exact value, it's more about "do the
driver and the hardware really provide _something_ sensible or not". In the
past, the default mode as to feed the output of hw_rng devies to some
userspace daemon, which then tried to verify that the device works as
expected, and then feeded the data back to the crng core. This userspace
indirection is largely removed already (in particular by a patch of mine
which starts up the hwrng kernel thread also for devices with quality==0)
once the crng is fully initialized, on the rationale that even bad quality
data will do no harm. Yet, we may need to be a tad more careful whether or
not to trust devices for the initial seeding of the crng.

Thanks,
Dominik

2022-11-07 09:28:49

by Harald Freudenberger

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

On 2022-11-04 16:42, Jason A. Donenfeld wrote:
> Most hw_random devices return entropy which is assumed to be of full
> quality, but driver authors don't bother setting the quality knob. Some
> hw_random devices return less than full quality entropy, and then
> driver
> authors set the quality knob. Therefore, the entropy crediting should
> be
> opt-out rather than opt-in per-driver, to reflect the actual reality on
> the ground.
>
> For example, the two Raspberry Pi RNG drivers produce full entropy
> randomness, and both EDK2 and U-Boot's drivers for these treat them as
> such. The result is that EFI then uses these numbers and passes the to
> Linux, and Linux credits them as boot, thereby initializing the RNG.
> Yet, in Linux, the quality knob was never set to anything, and so on
> the
> chance that Linux is booted without EFI, nothing is ever credited.
> That's annoying.
>
> The same pattern appears to repeat itself throughout various drivers.
> In
> fact, very very few drivers have bothered setting quality=1024.
>
> So let's invert this logic. A hw_random struct's quality knob now
> controls the maximum quality a driver can produce, or 0 to specify
> 1024.
> Then, the module-wide switch called "default_quality" is changed to
> represent the maximum quality of any driver. By default it's 1024, and
> the quality of any particular driver is then given by:
>
> min(default_quality, rng->quality ?: 1024);
>
> This way, the user can still turn this off for weird reasons, yet we
> get
> proper crediting for relevant RNGs.
>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> arch/um/drivers/random.c | 1 -
> drivers/char/hw_random/core.c | 9 +++------
> drivers/char/hw_random/mpfs-rng.c | 1 -
> drivers/char/hw_random/s390-trng.c | 1 -
> drivers/crypto/atmel-sha204a.c | 1 -
> drivers/crypto/caam/caamrng.c | 1 -
> drivers/firmware/turris-mox-rwtm.c | 1 -
> drivers/usb/misc/chaoskey.c | 1 -
> include/linux/hw_random.h | 2 +-
> 9 files changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
> index 32b3341fe970..da985e0dc69a 100644
> --- a/arch/um/drivers/random.c
> +++ b/arch/um/drivers/random.c
> @@ -82,7 +82,6 @@ static int __init rng_init (void)
> sigio_broken(random_fd);
> hwrng.name = RNG_MODULE_NAME;
> hwrng.read = rng_dev_read;
> - hwrng.quality = 1024;
>
> err = hwrng_register(&hwrng);
> if (err) {
> diff --git a/drivers/char/hw_random/core.c
> b/drivers/char/hw_random/core.c
> index cc002b0c2f0c..afde685f5e0a 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -41,14 +41,14 @@ static DEFINE_MUTEX(reading_mutex);
> static int data_avail;
> static u8 *rng_buffer, *rng_fillbuf;
> static unsigned short current_quality;
> -static unsigned short default_quality; /* = 0; default to "off" */
> +static unsigned short default_quality = 1024; /* default to maximum */
>
> module_param(current_quality, ushort, 0644);
> MODULE_PARM_DESC(current_quality,
> "current hwrng entropy estimation per 1024 bits of input --
> obsolete, use rng_quality instead");
> module_param(default_quality, ushort, 0644);
> MODULE_PARM_DESC(default_quality,
> - "default entropy content of hwrng per 1024 bits of input");
> + "default maximum entropy content of hwrng per 1024 bits of input");
>
> static void drop_current_rng(void);
> static int hwrng_init(struct hwrng *rng);
> @@ -170,10 +170,7 @@ static int hwrng_init(struct hwrng *rng)
> reinit_completion(&rng->cleanup_done);
>
> skip_init:
> - if (!rng->quality)
> - rng->quality = default_quality;
> - if (rng->quality > 1024)
> - rng->quality = 1024;
> + rng->quality = min_t(u16, min_t(u16, default_quality, 1024),
> rng->quality ?: 1024);
> current_quality = rng->quality; /* obsolete */
>
> return 0;
> diff --git a/drivers/char/hw_random/mpfs-rng.c
> b/drivers/char/hw_random/mpfs-rng.c
> index 5813da617a48..c6972734ae62 100644
> --- a/drivers/char/hw_random/mpfs-rng.c
> +++ b/drivers/char/hw_random/mpfs-rng.c
> @@ -78,7 +78,6 @@ static int mpfs_rng_probe(struct platform_device
> *pdev)
>
> rng_priv->rng.read = mpfs_rng_read;
> rng_priv->rng.name = pdev->name;
> - rng_priv->rng.quality = 1024;
>
> platform_set_drvdata(pdev, rng_priv);
>
> diff --git a/drivers/char/hw_random/s390-trng.c
> b/drivers/char/hw_random/s390-trng.c
> index 795853dfc46b..cffa326ddc8d 100644
> --- a/drivers/char/hw_random/s390-trng.c
> +++ b/drivers/char/hw_random/s390-trng.c
> @@ -191,7 +191,6 @@ static struct hwrng trng_hwrng_dev = {
> .name = "s390-trng",
> .data_read = trng_hwrng_data_read,
> .read = trng_hwrng_read,
> - .quality = 1024,
> };
>
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index a84b657598c6..c0103e7fc2e7 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -107,7 +107,6 @@ static int atmel_sha204a_probe(struct i2c_client
> *client,
>
> i2c_priv->hwrng.name = dev_name(&client->dev);
> i2c_priv->hwrng.read = atmel_sha204a_rng_read;
> - i2c_priv->hwrng.quality = 1024;
>
> ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng);
> if (ret)
> diff --git a/drivers/crypto/caam/caamrng.c
> b/drivers/crypto/caam/caamrng.c
> index 77d048dfe5d0..1f0e82050976 100644
> --- a/drivers/crypto/caam/caamrng.c
> +++ b/drivers/crypto/caam/caamrng.c
> @@ -246,7 +246,6 @@ int caam_rng_init(struct device *ctrldev)
> ctx->rng.cleanup = caam_cleanup;
> ctx->rng.read = caam_read;
> ctx->rng.priv = (unsigned long)ctx;
> - ctx->rng.quality = 1024;
>
> dev_info(ctrldev, "registering rng-caam\n");
>
> diff --git a/drivers/firmware/turris-mox-rwtm.c
> b/drivers/firmware/turris-mox-rwtm.c
> index c2d34dc8ba46..6ea5789a89e2 100644
> --- a/drivers/firmware/turris-mox-rwtm.c
> +++ b/drivers/firmware/turris-mox-rwtm.c
> @@ -528,7 +528,6 @@ static int turris_mox_rwtm_probe(struct
> platform_device *pdev)
> rwtm->hwrng.name = DRIVER_NAME "_hwrng";
> rwtm->hwrng.read = mox_hwrng_read;
> rwtm->hwrng.priv = (unsigned long) rwtm;
> - rwtm->hwrng.quality = 1024;
>
> ret = devm_hwrng_register(dev, &rwtm->hwrng);
> if (ret < 0) {
> diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc/chaoskey.c
> index 87067c3d6109..6fb5140e29b9 100644
> --- a/drivers/usb/misc/chaoskey.c
> +++ b/drivers/usb/misc/chaoskey.c
> @@ -200,7 +200,6 @@ static int chaoskey_probe(struct usb_interface
> *interface,
>
> dev->hwrng.name = dev->name ? dev->name : chaoskey_driver.name;
> dev->hwrng.read = chaoskey_rng_read;
> - dev->hwrng.quality = 1024;
>
> dev->hwrng_registered = (hwrng_register(&dev->hwrng) == 0);
> if (!dev->hwrng_registered)
> diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
> index 77c2885c4c13..8a3115516a1b 100644
> --- a/include/linux/hw_random.h
> +++ b/include/linux/hw_random.h
> @@ -34,7 +34,7 @@
> * @priv: Private data, for use by the RNG driver.
> * @quality: Estimation of true entropy in RNG's bitstream
> * (in bits of entropy per 1024 bits of input;
> - * valid values: 1 to 1024, or 0 for unknown).
> + * valid values: 1 to 1024, or 0 for maximum).
> */
> struct hwrng {
> const char *name;

Well, I am not sure if this is the right way to go. So by default a
hw rng which does not implement the registration correctly is
rewarded with the implicit assumption that it produces 100% of
entropy.
I see your point - a grep through the kernel code gives the impression
that a whole bunch of registrations is done with an empty quality
field. What about assuming a default quality of 50% if the field
is not filled ?

2022-11-07 11:25:31

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

Hi Dominik,

On Mon, Nov 07, 2022 at 08:35:02AM +0100, Dominik Brodowski wrote:
> Hi Jason,
>
> Am Sun, Nov 06, 2022 at 03:40:44PM +0100 schrieb Jason A. Donenfeld:
> > On Sun, Nov 06, 2022 at 08:05:25AM +0100, Dominik Brodowski wrote:
> > > Am Fri, Nov 04, 2022 at 04:42:30PM +0100 schrieb Jason A. Donenfeld:
> > > > Most hw_random devices return entropy which is assumed to be of full
> > > > quality, but driver authors don't bother setting the quality knob. Some
> > > > hw_random devices return less than full quality entropy, and then driver
> > > > authors set the quality knob. Therefore, the entropy crediting should be
> > > > opt-out rather than opt-in per-driver, to reflect the actual reality on
> > > > the ground.
> > > >
> > > > For example, the two Raspberry Pi RNG drivers produce full entropy
> > > > randomness, and both EDK2 and U-Boot's drivers for these treat them as
> > > > such. The result is that EFI then uses these numbers and passes the to
> > > > Linux, and Linux credits them as boot, thereby initializing the RNG.
> > > > Yet, in Linux, the quality knob was never set to anything, and so on the
> > > > chance that Linux is booted without EFI, nothing is ever credited.
> > > > That's annoying.
> > > >
> > > > The same pattern appears to repeat itself throughout various drivers. In
> > > > fact, very very few drivers have bothered setting quality=1024.
> > > >
> > > > So let's invert this logic. A hw_random struct's quality knob now
> > > > controls the maximum quality a driver can produce, or 0 to specify 1024.
> > > > Then, the module-wide switch called "default_quality" is changed to
> > > > represent the maximum quality of any driver. By default it's 1024, and
> > > > the quality of any particular driver is then given by:
> > > >
> > > > min(default_quality, rng->quality ?: 1024);
> > > >
> > > > This way, the user can still turn this off for weird reasons, yet we get
> > > > proper crediting for relevant RNGs.
> > >
> > > Hm. Wouldn't we need to verify that 1024 is appropriate for all drivers
> > > where the quality currently is not set?
> >
> > No, certainly not, and I think this sort of thought belies a really
> > backwards attitude. Hardware RNGs are assumed to produce good
> > randomness. Some manufacturers provide a caveat, "actually, we're giving
> > raw entropy with only N bits quality", but for the ones who don't, the
> > overarching assumption is that the bits are fully entropic.
>
> My point is not about the 1024 as an exact value, it's more about "do the
> driver and the hardware really provide _something_ sensible or not". In the
> past, the default mode as to feed the output of hw_rng devies to some
> userspace daemon, which then tried to verify that the device works as
> expected, and then feeded the data back to the crng core. This userspace
> indirection is largely removed already (in particular by a patch of mine
> which starts up the hwrng kernel thread also for devices with quality==0)
> once the crng is fully initialized, on the rationale that even bad quality
> data will do no harm. Yet, we may need to be a tad more careful whether or
> not to trust devices for the initial seeding of the crng.

I got your point, and I still think it's a bad one, for the reasons
already explained to you. If it's a hardware RNG, then it's sensible to
assume it provides hardware random bits, unless we have documentation
that says it provides something less than perfect.

Now you've moved on to talking again about entropy estimation. Stop with
this nonsense. Entropy estimation is an impossible proposition that
actually results in an infoleak. With that said, a self-test to make
sure the hardware isn't completely borked would be a nice thing, but
this applies for any device no matter what assumptions are made. So if
you want to work on that, go ahead, but it's completely orthogonal to
this change here.

Jason

2022-11-07 11:27:34

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

Hi Harald,

On Mon, Nov 07, 2022 at 10:24:42AM +0100, Harald Freudenberger wrote:
> Well, I am not sure if this is the right way to go. So by default a
> hw rng which does not implement the registration correctly is
> rewarded with the implicit assumption that it produces 100% of
> entropy.
> I see your point - a grep through the kernel code gives the impression
> that a whole bunch of registrations is done with an empty quality
> field. What about assuming a default quality of 50% if the field
> is not filled ?

The vast majority of hardware RNGs do *not* work this way. The
reasonable assumption is to assume that a hardware RNG provides fully
random bits, unless the documentation leads the driver author to specify
something less.

Really, just quit with all the nutty mailing list stuff here. Next: "how
about 74.4% because that matches the vibrations of cedar trees"... If
you want this to be different on a particular kernel, you can set your
exact value as a command line. This patch here is simply about a
sensible default.

Jason

2022-11-07 12:08:07

by Jason A. Donenfeld

[permalink] [raw]

Subject: Re: [PATCH] hw_random: treat default_quality as a maximum and default to 1024

On Mon, Nov 7, 2022 at 12:14 PM Jason A. Donenfeld <[email protected]> wrote:
>
> Hi Dominik,
>
> On Mon, Nov 07, 2022 at 08:35:02AM +0100, Dominik Brodowski wrote:
> > Hi Jason,
> >
> > Am Sun, Nov 06, 2022 at 03:40:44PM +0100 schrieb Jason A. Donenfeld:
> > > On Sun, Nov 06, 2022 at 08:05:25AM +0100, Dominik Brodowski wrote:
> > > > Am Fri, Nov 04, 2022 at 04:42:30PM +0100 schrieb Jason A. Donenfeld:
> > > > > Most hw_random devices return entropy which is assumed to be of full
> > > > > quality, but driver authors don't bother setting the quality knob. Some
> > > > > hw_random devices return less than full quality entropy, and then driver
> > > > > authors set the quality knob. Therefore, the entropy crediting should be
> > > > > opt-out rather than opt-in per-driver, to reflect the actual reality on
> > > > > the ground.
> > > > >
> > > > > For example, the two Raspberry Pi RNG drivers produce full entropy
> > > > > randomness, and both EDK2 and U-Boot's drivers for these treat them as
> > > > > such. The result is that EFI then uses these numbers and passes the to
> > > > > Linux, and Linux credits them as boot, thereby initializing the RNG.
> > > > > Yet, in Linux, the quality knob was never set to anything, and so on the
> > > > > chance that Linux is booted without EFI, nothing is ever credited.
> > > > > That's annoying.
> > > > >
> > > > > The same pattern appears to repeat itself throughout various drivers. In
> > > > > fact, very very few drivers have bothered setting quality=1024.
> > > > >
> > > > > So let's invert this logic. A hw_random struct's quality knob now
> > > > > controls the maximum quality a driver can produce, or 0 to specify 1024.
> > > > > Then, the module-wide switch called "default_quality" is changed to
> > > > > represent the maximum quality of any driver. By default it's 1024, and
> > > > > the quality of any particular driver is then given by:
> > > > >
> > > > > min(default_quality, rng->quality ?: 1024);
> > > > >
> > > > > This way, the user can still turn this off for weird reasons, yet we get
> > > > > proper crediting for relevant RNGs.
> > > >
> > > > Hm. Wouldn't we need to verify that 1024 is appropriate for all drivers
> > > > where the quality currently is not set?
> > >
> > > No, certainly not, and I think this sort of thought belies a really
> > > backwards attitude. Hardware RNGs are assumed to produce good
> > > randomness. Some manufacturers provide a caveat, "actually, we're giving
> > > raw entropy with only N bits quality", but for the ones who don't, the
> > > overarching assumption is that the bits are fully entropic.
> >
> > My point is not about the 1024 as an exact value, it's more about "do the
> > driver and the hardware really provide _something_ sensible or not". In the
> > past, the default mode as to feed the output of hw_rng devies to some
> > userspace daemon, which then tried to verify that the device works as
> > expected, and then feeded the data back to the crng core. This userspace
> > indirection is largely removed already (in particular by a patch of mine
> > which starts up the hwrng kernel thread also for devices with quality==0)
> > once the crng is fully initialized, on the rationale that even bad quality
> > data will do no harm. Yet, we may need to be a tad more careful whether or
> > not to trust devices for the initial seeding of the crng.
>
> I got your point, and I still think it's a bad one, for the reasons
> already explained to you. If it's a hardware RNG, then it's sensible to
> assume it provides hardware random bits, unless we have documentation
> that says it provides something less than perfect.
>
> Now you've moved on to talking again about entropy estimation. Stop with
> this nonsense. Entropy estimation is an impossible proposition that
> actually results in an infoleak. With that said, a self-test to make
> sure the hardware isn't completely borked would be a nice thing, but
> this applies for any device no matter what assumptions are made. So if
> you want to work on that, go ahead, but it's completely orthogonal to
> this change here.

Based on IRC discussion, following up with a v2 with a better commit message.

Jason

2022-11-07 12:26:21

by Jason A. Donenfeld

[permalink] [raw]

Subject: [PATCH v2] hw_random: treat default_quality as a maximum and default to 1024

Most hw_random devices return entropy which is assumed to be of full
quality, but driver authors don't bother setting the quality knob. Some
hw_random devices return less than full quality entropy, and then driver
authors set the quality knob. Therefore, the entropy crediting should be
opt-out rather than opt-in per-driver, to reflect the actual reality on
the ground.

For example, the two Raspberry Pi RNG drivers produce full entropy
randomness, and both EDK2 and U-Boot's drivers for these treat them as
such. The result is that EFI then uses these numbers and passes the to
Linux, and Linux credits them as boot, thereby initializing the RNG.
Yet, in Linux, the quality knob was never set to anything, and so on the
chance that Linux is booted without EFI, nothing is ever credited.
That's annoying.

The same pattern appears to repeat itself throughout various drivers. In
fact, very very few drivers have bothered setting quality=1024.

Looking at the git history of existing drivers and corresponding mailing
list discussion, this conclusion tracks. There's been a decent amount of
discussion about drivers that set quality < 1024 -- somebody read and
interepreted a datasheet, or made some back of the envelope calculation
somehow. But there's been very little, if any, discussion about most
drivers where the quality is just set to 1024 or unset (or set to 1000
when the authors misunderstood the API and assumed it was base-10 rather
than base-2); in both cases the intent was fairly clear of, "this is a
hardware random device; it's fine."

So let's invert this logic. A hw_random struct's quality knob now
controls the maximum quality a driver can produce, or 0 to specify 1024.
Then, the module-wide switch called "default_quality" is changed to
represent the maximum quality of any driver. By default it's 1024, and
the quality of any particular driver is then given by:

min(default_quality, rng->quality ?: 1024);

This way, the user can still turn this off for weird reasons (and we can
replace whatever driver-specific disabling hacks existed in the past),
yet we get proper crediting for relevant RNGs.

Cc: Dominik Brodowski <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Herbert Xu <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
Changes v1->v2:
- Expand commit message a bit.
- Account for erroneous quality=1000 and quirky devices too.

arch/um/drivers/random.c | 1 -
drivers/char/hw_random/cavium-rng-vf.c | 1 -
drivers/char/hw_random/cn10k-rng.c | 1 -
drivers/char/hw_random/core.c | 9 +++------
drivers/char/hw_random/mpfs-rng.c | 1 -
drivers/char/hw_random/npcm-rng.c | 1 -
drivers/char/hw_random/s390-trng.c | 1 -
drivers/char/hw_random/timeriomem-rng.c | 2 --
drivers/char/hw_random/virtio-rng.c | 1 -
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c | 1 -
drivers/crypto/atmel-sha204a.c | 1 -
drivers/crypto/caam/caamrng.c | 1 -
drivers/firmware/turris-mox-rwtm.c | 1 -
drivers/s390/crypto/zcrypt_api.c | 6 ------
drivers/usb/misc/chaoskey.c | 1 -
include/linux/hw_random.h | 2 +-
16 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index 32b3341fe970..da985e0dc69a 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -82,7 +82,6 @@ static int __init rng_init (void)
sigio_broken(random_fd);
hwrng.name = RNG_MODULE_NAME;
hwrng.read = rng_dev_read;
- hwrng.quality = 1024;

err = hwrng_register(&hwrng);
if (err) {
diff --git a/drivers/char/hw_random/cavium-rng-vf.c b/drivers/char/hw_random/cavium-rng-vf.c
index 7c55f4cf4a8b..c99c54cd99c6 100644
--- a/drivers/char/hw_random/cavium-rng-vf.c
+++ b/drivers/char/hw_random/cavium-rng-vf.c
@@ -225,7 +225,6 @@ static int cavium_rng_probe_vf(struct pci_dev *pdev,
return -ENOMEM;

rng->ops.read = cavium_rng_read;
- rng->ops.quality = 1000;

pci_set_drvdata(pdev, rng);

diff --git a/drivers/char/hw_random/cn10k-rng.c b/drivers/char/hw_random/cn10k-rng.c
index a01e9307737c..c1193f85982c 100644
--- a/drivers/char/hw_random/cn10k-rng.c
+++ b/drivers/char/hw_random/cn10k-rng.c
@@ -145,7 +145,6 @@ static int cn10k_rng_probe(struct pci_dev *pdev, const struct pci_device_id *id)
return -ENOMEM;

rng->ops.read = cn10k_rng_read;
- rng->ops.quality = 1000;
rng->ops.priv = (unsigned long)rng;

reset_rng_health_state(rng);
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 63a0a8e4505d..f34d356fe2c0 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -41,14 +41,14 @@ static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
static unsigned short current_quality;
-static unsigned short default_quality; /* = 0; default to "off" */
+static unsigned short default_quality = 1024; /* default to maximum */

module_param(current_quality, ushort, 0644);
MODULE_PARM_DESC(current_quality,
"current hwrng entropy estimation per 1024 bits of input -- obsolete, use rng_quality instead");
module_param(default_quality, ushort, 0644);
MODULE_PARM_DESC(default_quality,
- "default entropy content of hwrng per 1024 bits of input");
+ "default maximum entropy content of hwrng per 1024 bits of input");

static void drop_current_rng(void);
static int hwrng_init(struct hwrng *rng);
@@ -172,10 +172,7 @@ static int hwrng_init(struct hwrng *rng)
reinit_completion(&rng->cleanup_done);

skip_init:
- if (!rng->quality)
- rng->quality = default_quality;
- if (rng->quality > 1024)
- rng->quality = 1024;
+ rng->quality = min_t(u16, min_t(u16, default_quality, 1024), rng->quality ?: 1024);
current_quality = rng->quality; /* obsolete */

return 0;
diff --git a/drivers/char/hw_random/mpfs-rng.c b/drivers/char/hw_random/mpfs-rng.c
index 5813da617a48..c6972734ae62 100644
--- a/drivers/char/hw_random/mpfs-rng.c
+++ b/drivers/char/hw_random/mpfs-rng.c
@@ -78,7 +78,6 @@ static int mpfs_rng_probe(struct platform_device *pdev)

rng_priv->rng.read = mpfs_rng_read;
rng_priv->rng.name = pdev->name;
- rng_priv->rng.quality = 1024;

platform_set_drvdata(pdev, rng_priv);

diff --git a/drivers/char/hw_random/npcm-rng.c b/drivers/char/hw_random/npcm-rng.c
index 1ec5f267a656..4ec3e936b543 100644
--- a/drivers/char/hw_random/npcm-rng.c
+++ b/drivers/char/hw_random/npcm-rng.c
@@ -109,7 +109,6 @@ static int npcm_rng_probe(struct platform_device *pdev)
priv->rng.name = pdev->name;
priv->rng.read = npcm_rng_read;
priv->rng.priv = (unsigned long)&pdev->dev;
- priv->rng.quality = 1000;

writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);

diff --git a/drivers/char/hw_random/s390-trng.c b/drivers/char/hw_random/s390-trng.c
index 795853dfc46b..cffa326ddc8d 100644
--- a/drivers/char/hw_random/s390-trng.c
+++ b/drivers/char/hw_random/s390-trng.c
@@ -191,7 +191,6 @@ static struct hwrng trng_hwrng_dev = {
.name = "s390-trng",
.data_read = trng_hwrng_data_read,
.read = trng_hwrng_read,
- .quality = 1024,
};

diff --git a/drivers/char/hw_random/timeriomem-rng.c b/drivers/char/hw_random/timeriomem-rng.c
index 8ea1fc831eb7..26f322d19a88 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -145,8 +145,6 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev->dev.of_node,
"quality", &i))
priv->rng_ops.quality = i;
- else
- priv->rng_ops.quality = 0;
} else {
period = pdata->period;
priv->rng_ops.quality = pdata->quality;
diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c
index a6f3a8a2aca6..f7690e0f92ed 100644
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -148,7 +148,6 @@ static int probe_common(struct virtio_device *vdev)
.cleanup = virtio_cleanup,
.priv = (unsigned long)vi,
.name = vi->name,
- .quality = 1000,
};
vdev->priv = vi;

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
index c4b0a8b58842..e2b9b9104694 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
@@ -108,7 +108,6 @@ int sun8i_ce_hwrng_register(struct sun8i_ce_dev *ce)
}
ce->trng.name = "sun8i Crypto Engine TRNG";
ce->trng.read = sun8i_ce_trng_read;
- ce->trng.quality = 1000;

ret = hwrng_register(&ce->trng);
if (ret)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index a84b657598c6..c0103e7fc2e7 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -107,7 +107,6 @@ static int atmel_sha204a_probe(struct i2c_client *client,

i2c_priv->hwrng.name = dev_name(&client->dev);
i2c_priv->hwrng.read = atmel_sha204a_rng_read;
- i2c_priv->hwrng.quality = 1024;

ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng);
if (ret)
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 77d048dfe5d0..1f0e82050976 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -246,7 +246,6 @@ int caam_rng_init(struct device *ctrldev)
ctx->rng.cleanup = caam_cleanup;
ctx->rng.read = caam_read;
ctx->rng.priv = (unsigned long)ctx;
- ctx->rng.quality = 1024;

dev_info(ctrldev, "registering rng-caam\n");

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index c2d34dc8ba46..6ea5789a89e2 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -528,7 +528,6 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)
rwtm->hwrng.name = DRIVER_NAME "_hwrng";
rwtm->hwrng.read = mox_hwrng_read;
rwtm->hwrng.priv = (unsigned long) rwtm;
- rwtm->hwrng.quality = 1024;

ret = devm_hwrng_register(dev, &rwtm->hwrng);
if (ret < 0) {
diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index f94b43ce9a65..4bf36e53fe3e 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -53,10 +53,6 @@ MODULE_LICENSE("GPL");
EXPORT_TRACEPOINT_SYMBOL(s390_zcrypt_req);
EXPORT_TRACEPOINT_SYMBOL(s390_zcrypt_rep);

-static int zcrypt_hwrng_seed = 1;
-module_param_named(hwrng_seed, zcrypt_hwrng_seed, int, 0440);
-MODULE_PARM_DESC(hwrng_seed, "Turn on/off hwrng auto seed, default is 1 (on).");
-
DEFINE_SPINLOCK(zcrypt_list_lock);
LIST_HEAD(zcrypt_card_list);

@@ -2063,8 +2059,6 @@ int zcrypt_rng_device_add(void)
goto out;
}
zcrypt_rng_buffer_index = 0;
- if (!zcrypt_hwrng_seed)
- zcrypt_rng_dev.quality = 0;
rc = hwrng_register(&zcrypt_rng_dev);
if (rc)
goto out_free;
diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc/chaoskey.c
index 87067c3d6109..6fb5140e29b9 100644
--- a/drivers/usb/misc/chaoskey.c
+++ b/drivers/usb/misc/chaoskey.c
@@ -200,7 +200,6 @@ static int chaoskey_probe(struct usb_interface *interface,

dev->hwrng.name = dev->name ? dev->name : chaoskey_driver.name;
dev->hwrng.read = chaoskey_rng_read;
- dev->hwrng.quality = 1024;

dev->hwrng_registered = (hwrng_register(&dev->hwrng) == 0);
if (!dev->hwrng_registered)
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 77c2885c4c13..8a3115516a1b 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -34,7 +34,7 @@
* @priv: Private data, for use by the RNG driver.
* @quality: Estimation of true entropy in RNG's bitstream
* (in bits of entropy per 1024 bits of input;
- * valid values: 1 to 1024, or 0 for unknown).
+ * valid values: 1 to 1024, or 0 for maximum).
*/
struct hwrng {
const char *name;
--
2.38.1

2022-11-07 12:57:41

by Dominik Brodowski

[permalink] [raw]

Subject: Re: [PATCH v2] hw_random: treat default_quality as a maximum and default to 1024

On Mon, Nov 07, 2022 at 01:24:55PM +0100, Jason A. Donenfeld wrote:
> Most hw_random devices return entropy which is assumed to be of full
> quality, but driver authors don't bother setting the quality knob. Some
> hw_random devices return less than full quality entropy, and then driver
> authors set the quality knob. Therefore, the entropy crediting should be
> opt-out rather than opt-in per-driver, to reflect the actual reality on
> the ground.
>
> For example, the two Raspberry Pi RNG drivers produce full entropy
> randomness, and both EDK2 and U-Boot's drivers for these treat them as
> such. The result is that EFI then uses these numbers and passes the to
> Linux, and Linux credits them as boot, thereby initializing the RNG.
> Yet, in Linux, the quality knob was never set to anything, and so on the
> chance that Linux is booted without EFI, nothing is ever credited.
> That's annoying.
>
> The same pattern appears to repeat itself throughout various drivers. In
> fact, very very few drivers have bothered setting quality=1024.
>
> Looking at the git history of existing drivers and corresponding mailing
> list discussion, this conclusion tracks. There's been a decent amount of
> discussion about drivers that set quality < 1024 -- somebody read and
> interepreted a datasheet, or made some back of the envelope calculation
> somehow. But there's been very little, if any, discussion about most
> drivers where the quality is just set to 1024 or unset (or set to 1000
> when the authors misunderstood the API and assumed it was base-10 rather
> than base-2); in both cases the intent was fairly clear of, "this is a
> hardware random device; it's fine."
>
> So let's invert this logic. A hw_random struct's quality knob now
> controls the maximum quality a driver can produce, or 0 to specify 1024.
> Then, the module-wide switch called "default_quality" is changed to
> represent the maximum quality of any driver. By default it's 1024, and
> the quality of any particular driver is then given by:
>
> min(default_quality, rng->quality ?: 1024);
>
> This way, the user can still turn this off for weird reasons (and we can
> replace whatever driver-specific disabling hacks existed in the past),
> yet we get proper crediting for relevant RNGs.
>
> Cc: Dominik Brodowski <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>

Thanks for the additional explanation!

Reviewed-by: Dominik Brodowski <[email protected]>

Thanks,
Dominik

2022-11-18 09:15:38

by Herbert Xu

[permalink] [raw]

Subject: Re: [PATCH v2] hw_random: treat default_quality as a maximum and default to 1024

On Mon, Nov 07, 2022 at 01:24:55PM +0100, Jason A. Donenfeld wrote:
> Most hw_random devices return entropy which is assumed to be of full
> quality, but driver authors don't bother setting the quality knob. Some
> hw_random devices return less than full quality entropy, and then driver
> authors set the quality knob. Therefore, the entropy crediting should be
> opt-out rather than opt-in per-driver, to reflect the actual reality on
> the ground.
>
> For example, the two Raspberry Pi RNG drivers produce full entropy
> randomness, and both EDK2 and U-Boot's drivers for these treat them as
> such. The result is that EFI then uses these numbers and passes the to
> Linux, and Linux credits them as boot, thereby initializing the RNG.
> Yet, in Linux, the quality knob was never set to anything, and so on the
> chance that Linux is booted without EFI, nothing is ever credited.
> That's annoying.
>
> The same pattern appears to repeat itself throughout various drivers. In
> fact, very very few drivers have bothered setting quality=1024.
>
> Looking at the git history of existing drivers and corresponding mailing
> list discussion, this conclusion tracks. There's been a decent amount of
> discussion about drivers that set quality < 1024 -- somebody read and
> interepreted a datasheet, or made some back of the envelope calculation
> somehow. But there's been very little, if any, discussion about most
> drivers where the quality is just set to 1024 or unset (or set to 1000
> when the authors misunderstood the API and assumed it was base-10 rather
> than base-2); in both cases the intent was fairly clear of, "this is a
> hardware random device; it's fine."
>
> So let's invert this logic. A hw_random struct's quality knob now
> controls the maximum quality a driver can produce, or 0 to specify 1024.
> Then, the module-wide switch called "default_quality" is changed to
> represent the maximum quality of any driver. By default it's 1024, and
> the quality of any particular driver is then given by:
>
> min(default_quality, rng->quality ?: 1024);
>
> This way, the user can still turn this off for weird reasons (and we can
> replace whatever driver-specific disabling hacks existed in the past),
> yet we get proper crediting for relevant RNGs.
>
> Cc: Dominik Brodowski <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> Changes v1->v2:
> - Expand commit message a bit.
> - Account for erroneous quality=1000 and quirky devices too.
>
> arch/um/drivers/random.c | 1 -
> drivers/char/hw_random/cavium-rng-vf.c | 1 -
> drivers/char/hw_random/cn10k-rng.c | 1 -
> drivers/char/hw_random/core.c | 9 +++------
> drivers/char/hw_random/mpfs-rng.c | 1 -
> drivers/char/hw_random/npcm-rng.c | 1 -
> drivers/char/hw_random/s390-trng.c | 1 -
> drivers/char/hw_random/timeriomem-rng.c | 2 --
> drivers/char/hw_random/virtio-rng.c | 1 -
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c | 1 -
> drivers/crypto/atmel-sha204a.c | 1 -
> drivers/crypto/caam/caamrng.c | 1 -
> drivers/firmware/turris-mox-rwtm.c | 1 -
> drivers/s390/crypto/zcrypt_api.c | 6 ------
> drivers/usb/misc/chaoskey.c | 1 -
> include/linux/hw_random.h | 2 +-
> 16 files changed, 4 insertions(+), 27 deletions(-)

Patch applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt