Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Noah Meyerhans]

As detailed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948519 and
https://wiki.debian.org/BoottimeEntropyStarvation, lack of boot-time entropy
can contribute to multi-minute pauses during system initialization in some
hardware configurations.  While userspace workarounds, e.g. haveged, are
documented, the in-kernel jitter entropy collector eliminates the need for such
workarounds.

It cherry-picks cleanly to 4.19.y and 4.14.y.  I'm particularly interested
in the former.

Thanks for considering this.
noah

Re: Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Greg KH]

On Mon, Jan 27, 2020 at 06:02:14PM -0500, Noah Meyerhans wrote:
> As detailed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948519 and
> https://wiki.debian.org/BoottimeEntropyStarvation, lack of boot-time entropy
> can contribute to multi-minute pauses during system initialization in some
> hardware configurations.  While userspace workarounds, e.g. haveged, are
> documented, the in-kernel jitter entropy collector eliminates the need for such
> workarounds.
> 
> It cherry-picks cleanly to 4.19.y and 4.14.y.  I'm particularly interested
> in the former.
> 
> Thanks for considering this.

Please cc: the developers of that commit, and the maintainer of that
code, and we will be glad to consider it if they agree it is viable for
those kernels.

Personally, this looks like a "new feature" to me, if you really need
this, what is preventing you from moving to a newer kernel version?

thanks,

greg k-h

Re: Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Noah Meyerhans]

On Tue, Jan 28, 2020 at 08:52:23AM +0100, Greg KH wrote:
> > As detailed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948519 and
> > https://wiki.debian.org/BoottimeEntropyStarvation, lack of boot-time entropy
> > can contribute to multi-minute pauses during system initialization in some
> > hardware configurations.  While userspace workarounds, e.g. haveged, are
> > documented, the in-kernel jitter entropy collector eliminates the need for such
> > workarounds.
> > 
> > It cherry-picks cleanly to 4.19.y and 4.14.y.  I'm particularly interested
> > in the former.
> > 
> > Thanks for considering this.
> 
> Please cc: the developers of that commit, and the maintainer of that
> code, and we will be glad to consider it if they agree it is viable for
> those kernels.

Added torvalds and tytso to the CC list.  Linus and Ted, what do you
think of the idea of applying 50ee7529ec45 ("random: try to actively add
entropy rather than passively wait for it") to the 4.19.y and 4.14.y
kernels?

> Personally, this looks like a "new feature" to me, if you really need
> this, what is preventing you from moving to a newer kernel version?

From a personal perspective, I'm fine with moving to a newer kernel, but
for distributions it's not that simple.  The fact is, at the moment, the
current state of boot time entropy on systems running stable kernels on
systems without an HRNG-backed entropy source has lead to all manner of
workarounds being deployed.  While some of the workarounds may be fine,
others may be quite a bit less safe.  At least with the in-kernel jitter
entropy collector we can make things consistent.

Thanks
noah

Re: Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Linus Torvalds]

On Tue, Jan 28, 2020 at 11:34 AM Noah Meyerhans <noahm@debian.org> wrote:
>
> Added torvalds and tytso to the CC list.  Linus and Ted, what do you
> think of the idea of applying 50ee7529ec45 ("random: try to actively add
> entropy rather than passively wait for it") to the 4.19.y and 4.14.y
> kernels?

By now I suspect it's the right thing to do. Nobody has complained
about it, and it fixed real issues during boot.

Some of those real issues may have ended up being just unnecessary
delays rather than complete lockups, but still..

               Linus

Re: Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Theodore Y. Ts'o]

On Tue, Jan 28, 2020 at 11:59:28AM -0800, Linus Torvalds wrote:
> On Tue, Jan 28, 2020 at 11:34 AM Noah Meyerhans <noahm@debian.org> wrote:
> >
> > Added torvalds and tytso to the CC list.  Linus and Ted, what do you
> > think of the idea of applying 50ee7529ec45 ("random: try to actively add
> > entropy rather than passively wait for it") to the 4.19.y and 4.14.y
> > kernels?
> 
> By now I suspect it's the right thing to do. Nobody has complained
> about it, and it fixed real issues during boot.
> 
> Some of those real issues may have ended up being just unnecessary
> delays rather than complete lockups, but still..

FWIW, at $WORK we backported the patch, but we also added an out of
tree patch to disable it on non-x86 systems.  That's mainly because
I'm still hesitant about the safety of relying on this on non-x86
architectures that may have a much simpler micro-archtecture, and
which don't have RDRAND.  But we also have a much more stringent
(paranoid?) philosophy where if there is a risk that our kernels might
be penetrated by a nation-state (viz. Operation Aurora), booting
lockups so we know that we might have a problem that should be
examined by a human being is actually *preferable*.

But note that we work in a world where if there is a risk of exposure
to attacks that can be carried out by a nation state, we'd much rather
solve the problem in hardware (viz., a Titan Chip).

This is ultimately a security philosophy problem about what is more
important.  I'm not terribly worried about doing this for x86,
especially the more modern CPU's that have RDRAND.  I'm more worried
about doing this for say, ARM and RISC-V.  The RISC-V folks haven't
returned my queries; I haven't had the time to try to find some ARM
experts, although the real problem is there are so many different
implementations of the ARM architecture, that what might be applicable
for one architecture might not be for another.

So I'm not super-enthusiastic about backporting the commit to the
stable kernels, but I'm not going to object, either.

Cheers,
						- Ted

P.S.  And for VM's, the real right answer is virtio-rng (since if you
don't trust the hypervisor or the entity running the host OS, you have
no business using a VM in the first place), but I've had this
discussion with Noah on another forum.  :-)

Re: Please apply 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") to 4.19.y

[Greg KH]

On Wed, Jan 29, 2020 at 07:39:39PM -0500, Theodore Y. Ts'o wrote:
> On Tue, Jan 28, 2020 at 11:59:28AM -0800, Linus Torvalds wrote:
> > On Tue, Jan 28, 2020 at 11:34 AM Noah Meyerhans <noahm@debian.org> wrote:
> > >
> > > Added torvalds and tytso to the CC list.  Linus and Ted, what do you
> > > think of the idea of applying 50ee7529ec45 ("random: try to actively add
> > > entropy rather than passively wait for it") to the 4.19.y and 4.14.y
> > > kernels?
> > 
> > By now I suspect it's the right thing to do. Nobody has complained
> > about it, and it fixed real issues during boot.
> > 
> > Some of those real issues may have ended up being just unnecessary
> > delays rather than complete lockups, but still..
> 
> FWIW, at $WORK we backported the patch, but we also added an out of
> tree patch to disable it on non-x86 systems.  That's mainly because
> I'm still hesitant about the safety of relying on this on non-x86
> architectures that may have a much simpler micro-archtecture, and
> which don't have RDRAND.  But we also have a much more stringent
> (paranoid?) philosophy where if there is a risk that our kernels might
> be penetrated by a nation-state (viz. Operation Aurora), booting
> lockups so we know that we might have a problem that should be
> examined by a human being is actually *preferable*.

Ok, I've applied this to 4.19.y.  I'm guessing that anyone who had this
type of problem in 4.14.y has long upgraded their kernels, and that
kernel is pretty much only in already-shipping devices, not "new"
things.

Let's see what breaks :)

thanks,

greg k-h