[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fix for no ssh



On 2019-07-10, Andy Smith <andy@strugglers.net> wrote:

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

I said users don't read the release notes? I don't remember saying that.
I remember saying we can't assume or expect the "regular user" (for any
arbitrary definition of that) is following the technical discussions of
the development team. I do think, though, all users are responsible for
reading the release notes. That's life in the big city, as Mom used to
say. 

>> 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 for those with a recent kernel, who have a cpu that supports the
RDRAND instruction, to unset the 'CONFIG_RANDOM_TRUST_CPU' default, they
should put 'random.trust_cpu=off' on the kernel command line? And for
those using a less recent kernel with a cpu that supports the RDRAND
instruction, it might be enough not to add "random.trust_cpu=on" to the
kernel command line?

Sorry, but I'm still unclear about this.

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

His views shouldn't be "represented" at all. I thought it would be
honest to have something brief, up front, and simple, in the notes
themselves, like:

 For amd64 systems supporting the RDRAND instruction this issue is
 avoided by the Debian kernel using this instruction by default
 (CONFIG_RANDOM_TRUST_CPU). There are security implications in regard to
 applying this default in the view of some. See the comments of Theodore
 Ts'o (author of the patch) about this config option here:

 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a8883a2b989d1d21bd8dd99f5557f0c5e89694

Sufficiently wishy-washy, I think (*on ne se mouille pas trop*), and those
who travel to the link can interpret Ts'o's remarks via their own brains
and arrive at their own conclusions inside of same. 

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

What about jiggling my mouse for a while?

> Cheers,
> Andy
>


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 


Reply to: