From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: 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: Tue, 17 Jul 2018 21:51:54 -0400 [thread overview]
Message-ID: <20180718015154.GE3489@thunk.org> (raw)
In-Reply-To: <20180718014344.1309-1-tytso@mit.edu>
On Tue, Jul 17, 2018 at 09:43:44PM -0400, Theodore Ts'o wrote:
> 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).
>
> This will prevent getrandom(2) from blocking, if there is a
> willingness to trust the CPU manufacturer.
>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Note, I had meant to tag this with an RFC. I'm not sure I really want
to push this to Linus yet. If you have an opinion, let me know.
Thanks!
- Ted
> ---
>
> 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.
> +
> 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;
> }
>
> --
> 2.18.0.rc0
>
next prev parent reply other threads:[~2018-07-18 1:51 UTC|newest]
Thread overview: 21+ 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 [this message]
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
2018-07-18 14:26 ` Theodore Y. Ts'o
2018-07-18 15:29 ` Yann Droneaud
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=20180718015154.GE3489@thunk.org \
--to=tytso@mit.edu \
--cc=labbott@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.