Hi Curt,
On Wed, Jul 10, 2019 at 09:26:31AM -0000, Curt wrote:
> On 2019-07-10, Andy Smith <a...@strugglers.net> wrote:
> > But, let's say this use of RDRAND to supply boot-time entropy is as
> > serious as you argue. What would be your suggested configuration
>
> I would like Debian to make it clear in the release-notes that there are
> security implications to the application of the patch, as expressed by
> its author in the patch itself. This seems like a strict minimum for the
> "universal operating system" devoted to free software, open standards,
> and user choice.
So firstly, I feel that you are taking Ted Ts'o's remarks in the
patch too strongly. I interpret them as letting us know that there
is some concern over whether RDRAND could have been compromised, but
not telling us not to use it for this purpose, which seems to me to
be how you take it. I don't think that Ted would have contributed
the patch if he felt like it was very bad to use it, and I do take
his earlier objection in 2013 to be evidence that he wouldn't make a
change that he felt was a bad idea even if some people wanted it.
However we are then back to debating over our guesses as to what Ted
Ts'o thinks rather than anything objective, so I think we'll just
have to agree to disagree on that.
Secondly, the reason I asked you what you would like done is that in
the message I replied to you said that the release notes were
something that users don't read. But your proposed solution is to
put more things in the release notes.
> Further, I would like to know whether the patch will be "baked into the
> kernel" or whether it can be toggled on and/or off at the *user's*
> discretion. I don't remember being clear on this point after reading the
> notes (maybe it's there and I missed it).
>
> It wasn't clear to me, either, in the release-notes, the recommended way
> forward for those with amd64 cpus lacking the RDRAND instruction (and who
> therefore cannot "benefit" from the patch).
In the release notes in the relevant section (5.1.4) the last
paragraph is:
See the wiki (https://wiki.debian.org/BoottimeEntropyStarvation)
and DLange's overview of the issue
(https://daniel-lange.com/archives/152-hello-buster.html) for
other options.
Both those pages have a list of different solutions and both mention
that this RDRAND thing is enabled. Neither of them say how to
disable it but they do say:
for amd64: use a recent kernel with CONFIG_RANDOM_TRUST_CPU set
(less recent kernels may need random.trust_cpu=on added to the
commandline)
which kind of makes it obvious to me that to disable it you would do
"random.trust_cpu=off". If you don't find this obvious maybe the
wiki page could do with editing to improve that.
So what's lacking? Is it just that the release notes and linked
pages mention that the user trusts the CPU but do not mention why
some feel that is a bad idea?
Maybe you could draft an extra paragraph for the release notes that
contains a suitable warning? Although I do think if you are going to
use the "even the author of the patch thinks it's bad!" argument
then you should probably check with Ted Ts'o that that's an accurate
representation of his views on using RDRAND for boot-time entropy.
As for the recommended way forward, I'm not sure that there is an
easy answer if RDRAND isn't an option. There are complex trade-offs
and I think it's probably right that users in this position read the
wiki page and work out what's best for them.
I do note that for a person in your situation (real hardware [not a
virtual machine] with no RDRAND and no TPM), every listed solution
has at least one expert that says it is a very bad idea! I don't
think there is consensus here yet.
In your position I think I'd probably hold my nose (as it says) and
use haveged.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
