Hi Nicholas,
On Mon, Jul 08, 2019 at 04:49:00PM -0500, Nicholas Geovanis wrote:
> On Mon, Jul 8, 2019 at 3:45 PM Andy Smith <a...@strugglers.net> wrote:
> > Flash forward to 2017 and T'so himself wrote a patch to add a
> > configure option to allow RDRAND to be used early on to bootstrap
> > entropy. Thereafter it would not be the exclusive source of entropy.
> > That is what has been enabled in buster's kernel and is what is at
> > the heart of this discussion.
> > These are two different scenarios.
>
> Granted, they are different scenarios.
> But I don't ever recall the mainstream kernel in a leading
> distribution blocking on lack of entropy by default at any time in
> T'so's career. Until now. Sure, it looks like the source permitted
> blocking all along (maybe). But I never heard of this being used
> in a non-custom-built mainstream distro before.
> Has T'so had any comments on that? Does he find it appropriate or wise?
This whole getrandom()-can-block thing has been going on for
multiple years; it has been a huge debate within the Linux
development community. I'd have to read it all again I think to try
to summarise Theodore T'so's position on all of it, and I don't
really want to do that.
There was good coverage in LWN:
https://lwn.net/Articles/760584/
> > This sub-thread appears to have people concerned about the Debian
> > kernel's willingness by default to use RDRAND at early boot (a patch
> > which T'so wrote), but using a statement made by T'so in 2013 about
> > something else to oppose it.
>
> OK. You imply that their concerns were misguided (I wasn't one of them).
For the avoidance of doubt, I think that if we don't trust our CPUs
then we start to go down the rabbit hole where we can't trust
anything. HOWEVER…
Theodore T'so himself has made the argument that most places you
might compromise a CPU involve big teams of people and keeping the
secret that it's happened would likely be infeasible. Not so RDRAND,
which is thought to be the work of one or a small team of
developers, and which would be very easy to compromise.
So, as far as I understand it, that is why T'so opposed the use of
RDRAND as the *only* entropy source for Linux, but T'so in fact
*suggests* the use of RDRAND in tandem with other entropy sources as
a means to avoid boot-time entropy starvation. Because it's one of
the easiest ways to get around that problem, and even if compromised
isn't going to do any harm when mixed in.
That sounds sensible to me so I would agree with him that RDRAND is
suspicious but usable in that context. And I do go so far as to
provide entropy from external hardware sources for me and my
customers since 2013.
Actually I just tested this earlier in a new buster VM and by
default:
[ 1.170404] random: crng done (trusting CPU's manufacturer)
With 'nordrand' kernel command line and no use of external entropy:
[ 1.231884] random: fast init done
[ 48.655256] random: crng init done
with 'nordrand' and external entropy:
[ 10.879583] random: crng init done
The daemon for the external entropy starts quite late so I may be
able to improve matters by forcing it to start earlier, but I'm okay
with leaving RDRAND enabled so am not going to spend too much effort
on this.
> The evidence they chose may be untenable. But you have not
> addressed their actual concern.
I don't know whether you mean their concern about RDRAND possibly
being unsafe, or their concern about Debian choosing to make use of
it even though some believe it may be unsafe. Your next bit makes me
think you mean the latter so that's what I'll go with.
> I'm sure that your answer will include "....but the standard
> debian process to include this new feature in the kernel was
> followed......". So everything is OK. Right?
How to solve the "lack of entropy at boot time" problem was
discussed at length on debian-devel multiples times over multiple
years and that's how the wiki page at:
https://wiki.debian.org/BoottimeEntropyStarvation
came to exist. That page links to two of the debian-devel threads
and in those threads Theodore T'so did give some recommendations.
Debian developers made a decision based on those discussions which
were held in the open. I'm not sure who it fell to, to make the
ultimate decision. Probably the kernel team as they decided whether
to enable the RDRAND option? It's a tricky problem without a perfect
solution. Not everyone will be happy with the outcome, though there
does seem to be enough configurability there for them to have things
work differently, with different trade-offs.
If this has come as a surprise to some Debian users, that is only
because they didn't choose to get involved in such a deeply
technical discussion.
It's not that unusual that some users get upset by developer
decisions and isn't usually worth commenting upon, but it struck me
that in this sub-thread there is a particularly big misunderstanding
going on, as some are quoting T'so in a completely different context
as support for their argument against a situation which T'so was in
fact instrumental in bringing about!
I think there is possibly a lack of appreciation for the complexity
of this problem and so what has happened is someone has stumbled
across a quote and thought, "hey, Theodore T'so doesn't like RDRAND
and here we are using RDRAND! What gives!?"
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
