lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 7 Feb 2019 11:25:11 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Greg KH <greg@...ah.com>
CC:     Sasha Levin <sashal@...nel.org>,
        "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@...ia.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 4.14 "random: add a config option to trust the CPU's hwrng"

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@....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@...omium.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ