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

Re: fix for no ssh


On Wed, Jul 10, 2019 at 11:46:33AM +0000, Andy Smith wrote:
> > 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).
> ... 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".

Pfft. Wiki. Trust the source (in this case, drivers/char/random.c with
Debian patches applied):

static bool trust_cpu __ro_after_init =
static int __init parse_trust_cpu(char *arg)
    return kstrtobool(arg, &trust_cpu);
early_param("random.trust_cpu", parse_trust_cpu);

First things first, CONFIG_RANDOM_TRUST_CPU (the name could use some
improvement. Is it "trust randomly"? "random trusts cpu"? Whatever) is a
simple default value, there's no #ifdefs.
Second, a kernel parses cmdline (aka /proc/cmdline), to set "trust"
value if it encounters "random.trust_cpu=foo".

Second, this wonderful remark (you don't have a usable /dev/urandom
immediately after the boot):

 * Get a random word for internal kernel use only. The quality of the
 * random number is either as good as RDRAND or as good as /dev/urandom,
 * with the goal of being quite fast and not depleting entropy.

So, you trust RDRAND for the initial internal kernel CRNG initialization
as there's nothing else. If it's controlled by certain three letter
acronym agency - your kernel is screwed big time right after the boot.

The good news are - it's x86(_64) only (and if you're using it there are
*other* creative ways to screw you), and it can be disabled with


Reply to: