4.14 "random: add a config option to trust the CPU's hwrng"

4.14 "random: add a config option to trust the CPU's hwrng"

[Rantala, Tommi T. (Nokia - FI/Espoo)]

Hi stable maintainers,

Can you consider including these "random" patches in 4.14.y?

These are very useful in fixing esp. first-bootup delays of VMs due to
entropy starvation.


commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Jul 17 18:24:27 2018 -0400

    random: add a config option to trust the CPU's hwrng

commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Aug 27 14:51:54 2018 -0700

    random: make CPU trust a boot parameter


-Tommi

Re: 4.14 "random: add a config option to trust the CPU's hwrng"

[Sasha Levin]

On Wed, Feb 06, 2019 at 11:44:36AM +0000, Rantala, Tommi T. (Nokia - FI/Espoo) wrote:
>Hi stable maintainers,
>
>Can you consider including these "random" patches in 4.14.y?
>
>These are very useful in fixing esp. first-bootup delays of VMs due to
>entropy starvation.
>
>
>commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Tue Jul 17 18:24:27 2018 -0400
>
>    random: add a config option to trust the CPU's hwrng
>
>commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
>Author: Kees Cook <keescook@chromium.org>
>Date:   Mon Aug 27 14:51:54 2018 -0700
>
>    random: make CPU trust a boot parameter

This really looks like a new feature to me. The "old" behaviour of not
trusting RDRAND-like randomness was by-design rather than an oversight.

--
Thanks,
Sasha

Re: 4.14 "random: add a config option to trust the CPU's hwrng"

[Greg KH]

On Wed, Feb 06, 2019 at 02:26:13PM -0500, Sasha Levin wrote:
> On Wed, Feb 06, 2019 at 11:44:36AM +0000, Rantala, Tommi T. (Nokia - FI/Espoo) wrote:
> > Hi stable maintainers,
> > 
> > Can you consider including these "random" patches in 4.14.y?
> > 
> > These are very useful in fixing esp. first-bootup delays of VMs due to
> > entropy starvation.
> > 
> > 
> > commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
> > Author: Theodore Ts'o <tytso@mit.edu>
> > Date:   Tue Jul 17 18:24:27 2018 -0400
> > 
> >    random: add a config option to trust the CPU's hwrng
> > 
> > commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
> > Author: Kees Cook <keescook@chromium.org>
> > Date:   Mon Aug 27 14:51:54 2018 -0700
> > 
> >    random: make CPU trust a boot parameter
> 
> This really looks like a new feature to me. The "old" behaviour of not
> trusting RDRAND-like randomness was by-design rather than an oversight.

I agree with Sasha, this looks like a new feature.  If you really want
this new functionality, just use 4.19 or newer, right?

thanks,

greg k-h

Re: 4.14 "random: add a config option to trust the CPU's hwrng"

[Theodore Y. Ts'o]

On Thu, Feb 07, 2019 at 12:28:09PM +0100, Greg KH wrote:
> > > These are very useful in fixing esp. first-bootup delays of VMs due to
> > > entropy starvation.
> > > 
> > > 
> > > commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
> > > Author: Theodore Ts'o <tytso@mit.edu>
> > > Date:   Tue Jul 17 18:24:27 2018 -0400
> > > 
> > >    random: add a config option to trust the CPU's hwrng
> > > 
> > > commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
> > > Author: Kees Cook <keescook@chromium.org>
> > > Date:   Mon Aug 27 14:51:54 2018 -0700
> > > 
> > >    random: make CPU trust a boot parameter
> > 
> > This really looks like a new feature to me. The "old" behaviour of not
> > trusting RDRAND-like randomness was by-design rather than an oversight.
> 
> I agree with Sasha, this looks like a new feature.  If you really want
> this new functionality, just use 4.19 or newer, right?

This is a borderline case in my opinion.  The argument for why this
should perhaps be backported is the patches to address CVE-2018-1108,
which were backported to stable kernels, cause kernel boots to hang.
So to the extent that a newer stable kernel would cause operational
problems for consumers of the stable kernels, they would pretty
naturally view it as a regression.

Whether or not this should justify an exception is a policy question
that I'll leave to the stable kernel maintainers.  The downside is
that some consumers might elect to stay on an older stable kernel
since it would work for them, and newer stable kernels would not work.
Whether this is outweighed by prodding stable kernels users to new
newer kernels is an interesting question.

						- Ted