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
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
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
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
linux-stable-mirror@lists.linaro.org