From: Yann Droneaud <ydroneaud@opteya.com>
To: Theodore Ts'o <tytso@mit.edu>,
linux-crypto@vger.kernel.org,
Linux Kernel Developers List <linux-kernel@vger.kernel.org>
Cc: labbott@redhat.com
Subject: Re: [PATCH] random: add a config option to trust the CPU's hwrng
Date: Wed, 18 Jul 2018 09:22:13 +0200 [thread overview]
Message-ID: <37046662f2b38f98854abfa1b5868a27c3fa0888.camel@opteya.com> (raw)
In-Reply-To: <20180718014344.1309-1-tytso@mit.edu>
Hi,
Le mardi 17 juillet 2018 à 21:43 -0400, Theodore Ts'o a écrit :
> This gives the user building their own kernel (or a Linux
> distribution) the option of deciding whether or not to trust the CPU's
> hardware random number generator (e.g., RDRAND for x86 CPU's) as being
> correctly implemented and not having a back door introduced (perhaps
> courtesy of a Nation State's law enforcement or intelligence
> agencies).
>
A build time option (RANDOM_TRUST_CPU) is good, but I would also see a
kernel command line boot option for the user to disable the behavior
whenever its distro kernel was built with RANDOM_TRUST_CPU.
It would allow the end-user to make its own decision regarding CPU
based hwrng.
In particular, during distro installation, end-user doesn't have a
chance to rebuild the kernel beforehand, but he can tweak kernel
command line during distro installation boot.
> This will prevent getrandom(2) from blocking, if there is a
> willingness to trust the CPU manufacturer.
It would block during initialization / early boot.
>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>
> I'm not sure Linux distro's will thank us for this. The problem is
> trusting the CPU manfuacturer can be an emotional / political issue.
>
> For example, assume that China has decided that as a result of the
> "death sentence" that the US government threatened to impose on ZTE
> after they were caught introducing privacy violating malware on US
> comsumers, that they needed to be self-sufficient in their technology
> sector, and so they decided the needed to produce their own CPU.
>
> Even if I were convinced that Intel hadn't backdoored RDRAND (or an
> NSA agent backdoored RDRAND for them) such that the NSA had a NOBUS
> (nobody but us) capability to crack RDRAND generated numbers, if we
> made a change to unconditionally trust RDRAND, then I didn't want the
> upstream kernel developers to have to answer the question, "why are
> you willing to trust Intel, but you aren't willing to trust a company
> owned and controlled by a PLA general?" (Or a company owned and
> controlled by one of Putin's Oligarchs, if that makes you feel
> better.)
>
> With this patch, we don't put ourselves in this position --- but we
> do put the Linux distro's in this position intead. The upside is it
> gives the choice to each person building their own Linux kernel to
> decide whether trusting RDRAND is worth it to avoid hangs due to
> userspace trying to get cryptographic-grade entropy early in the boot
> process. (Note: I trust RDRAND more than I do Jitter Entropy.)
>
> drivers/char/Kconfig | 14 ++++++++++++++
> drivers/char/random.c | 11 ++++++++++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 212f447938ae..fe2930c4ecf0 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -554,3 +554,17 @@ config ADI
>
> endmenu
>
> +config RANDOM_TRUST_CPU
> + bool "Trust the CPU manufacturer to initialize Linux's CRNG"
> + depends on (X86 || X86_64 || X86_32 || S390 || PPC)
> + default n
> + help
> + Assume that CPU manufacurer (e.g., Intel or AMD for RDSEED or
> + RDRAND, IBM for the S390 and Power PC architectures) is trustworthy
> + for the purposes of initializing Linux's CRNG. Since this is not
> + something that can be indepedently audited, this amounts to trusting
> + that CPU manufacturer (perhaps with the insistance or requirement
> + of a Nation State's intelligence or law enforcement agencies)
> + has not installed a hidden back door to compromise the CPU's
> + random number generation facilities.
> +
The text message should explain this is only relevant during
initialization / early boot.
The config option name should state this.
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 34ddfd57419b..f4013b8a711b 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -782,6 +782,7 @@ static void invalidate_batched_entropy(void);
> static void crng_initialize(struct crng_state *crng)
> {
> int i;
> + int arch_init = 1;
> unsigned long rv;
>
> memcpy(&crng->state[0], "expand 32-byte k", 16);
> @@ -792,10 +793,18 @@ static void crng_initialize(struct crng_state *crng)
> _get_random_bytes(&crng->state[4], sizeof(__u32) * 12);
> for (i = 4; i < 16; i++) {
> if (!arch_get_random_seed_long(&rv) &&
> - !arch_get_random_long(&rv))
> + !arch_get_random_long(&rv)) {
> rv = random_get_entropy();
> + arch_init = 0;
> + }
> crng->state[i] ^= rv;
> }
> +#ifdef CONFIG_RANDOM_TRUST_CPU
> + if (arch_init) {
> + crng_init = 2;
> + pr_notice("random: crng done (trusting CPU's manufacturer)\n");
> + }
> +#endif
> crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
> }
>
Regards.
--
Yann Droneaud
OPTEYA
next prev parent reply other threads:[~2018-07-18 7:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 1:43 [PATCH] random: add a config option to trust the CPU's hwrng Theodore Ts'o
2018-07-18 1:51 ` Theodore Y. Ts'o
2018-07-18 15:14 ` Sandy Harris
2018-07-18 17:36 ` [PATCH] random: addu " Theodore Y. Ts'o
2018-07-18 20:22 ` Sandy Harris
2018-07-19 14:21 ` Theodore Y. Ts'o
2018-07-19 20:17 ` Yann Droneaud
2018-07-18 17:36 ` [PATCH] random: add " Ken Moffat
2018-07-19 0:19 ` Ken Moffat
2018-07-18 5:09 ` Randy Dunlap
2018-07-18 6:46 ` Jeffrey Walton
2018-07-18 7:22 ` Yann Droneaud [this message]
2018-07-18 14:26 ` Theodore Y. Ts'o
2018-07-18 15:29 ` Yann Droneaud
2018-07-18 19:17 ` Theodore Y. Ts'o
2018-08-04 21:52 ` Pavel Machek
2018-08-05 0:25 ` Theodore Y. Ts'o
2018-08-05 0:28 ` Theodore Y. Ts'o
2018-08-05 9:44 ` Pavel Machek
2018-07-20 19:09 ` Laura Abbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37046662f2b38f98854abfa1b5868a27c3fa0888.camel@opteya.com \
--to=ydroneaud@opteya.com \
--cc=labbott@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).