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 <[email protected]>
---
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
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 <[email protected]>
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
>
On 07/17/2018 06:43 PM, 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 <[email protected]>
> ---
>
> 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
>
Hi Ted,
In case you go further with this:
> +config RANDOM_TRUST_CPU
> + bool "Trust the CPU manufacturer to initialize Linux's CRNG"
> + depends on (X86 || X86_64 || X86_32 || S390 || PPC)
depends on X86 || S390 || PPC
should be sufficient.
> + default n
> + help
and all 4 lines above should be indented with one tab instead of spaces.
> + Assume that CPU manufacurer (e.g., Intel or AMD for RDSEED or
manufacturer
> + 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
independently
> + that CPU manufacturer (perhaps with the insistance or requirement
insistence
> + 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.
--
~Randy
On Tue, Jul 17, 2018 at 9:43 PM, Theodore Ts'o <[email protected]> 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).
+1.
Allowing the user to set local policy is a good idea. Thanks for that.
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 <[email protected]>
> ---
>
> 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
On Wed, Jul 18, 2018 at 09:22:13AM +0200, Yann Droneaud wrote:
>
> The text message should explain this is only relevant during
> initialization / early boot.
>
> The config option name should state this.
There are other workarounds for hangs that happen after initialization
/ early boot, yes. They are of varying levels of quality / safely,
but that's neither here nor there.
However, enabling config option means that the CRNG will be
initialized with potentially information available to the CPU
manufacturer and/or Nation States, and this persists *after*
initialization / early boot. So to say, "we're perfectly safe after
we leave initialization / early boot" is not true.
So I'd much rather make it clear that we are trusting the CPU
manufacturer far more than just during early boot.
Cheers,
- Ted
On Tue, Jul 17, 2018 at 9:51 PM, Theodore Y. Ts'o <[email protected]> wrote:
> 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 <[email protected]>
>
> 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.
I had something like this in patches I suggested as RFC a couple of
years back. Those patches were rejected for other reasons, quite
likely valid ones.
My version was not binary like this:
>> +config RANDOM_TRUST_CPU
>> + bool "Trust the CPU manufacturer to initialize Linux's CRNG"
Instead, I had a compile-time option to choose a number 0-32
for how much entropy to assume a 32-bit value from the HWRNG
contains. Default was something less than 32. I debated values
in the 24-30 range, don't recall what I chose & don't think it
Matters hugely.
Is that a better approach than the binary choice?
Hi,
Le mercredi 18 juillet 2018 à 10:26 -0400, Theodore Y. Ts'o a écrit :
> On Wed, Jul 18, 2018 at 09:22:13AM +0200, Yann Droneaud wrote:
> >
> > The text message should explain this is only relevant during
> > initialization / early boot.
> >
> > The config option name should state this.
>
> There are other workarounds for hangs that happen after
> initialization / early boot, yes. They are of varying levels of
> quality / safely, but that's neither here nor there.
>
> However, enabling config option means that the CRNG will be
> initialized with potentially information available to the CPU
> manufacturer and/or Nation States, and this persists *after*
> initialization / early boot. So to say, "we're perfectly safe after
> we leave initialization / early boot" is not true.
>
Sure, but, AFAICT, RDRAND is already in use through arch_get_random_*()
functions when CONFIG_ARCH_RANDOM is enabled.
>From an outside PoV, there's a conflict: why one would want its kernel
to use CPU hwrng if one has purposely disabled CONFIG_RANDOM_TRUST_CPU
?
> So I'd much rather make it clear that we are trusting the CPU
> manufacturer far more than just during early boot.
>
Then, should CONFIG_ARCH_RANDOM depends on CONFIG_RANDOM_TRUST_CPU (on
x86 at least) ?
Regards.
--
Yann Droneaud
OPTEYA
On 18 July 2018 at 02:51, Theodore Y. Ts'o <[email protected]> wrote:
> 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 <[email protected]>
(Apologies if this is a duplicate reply, I misread the tiny text in gmail asking
me if it was ok to send non plain text (dunno what caused that), so I guess
the first version went to /dev/null, at least as far as the list is concerned.)
On my haswell, since 4.16.4 and the corresponding 4.17-rc. my (sysv)
bootscript to start unbound hangs for a couple of minutes unless I use the
keyboard. Same on my kaveri. Those both lack spinning rust, but on two
other SSD-only machines (ryzen, phenom) the security fix did not slow down
the boot.
So, since I've got better things to do than _worry_ about than whether my
government, or yours, is spying on me, I would prefer to have the option to
take the risk on the machines that will then boot faster.
ĸen
On Wed, Jul 18, 2018 at 11:14:20AM -0400, Sandy Harris wrote:
> Instead, I had a compile-time option to choose a number 0-32
> for how much entropy to assume a 32-bit value from the HWRNG
> contains. Default was something less than 32. I debated values
> in the 24-30 range, don't recall what I chose & don't think it
> Matters hugely.
>
> Is that a better approach than the binary choice?
This patch is only affecting the initialization of the CRNG. It
doesn't do anything about the entropy estimator, so it doesn't change
the behavior of /dev/random, for example.
In practice I doubt most people would be able to deal with a numerical
dial, and I'm trying to ecourage people to use getrandom(2). I view
/dev/random as a legacy interface, and for most people a CRNG is quite
sufficient. For those people who are super paranoid and want a "true
random number generator" (and the meaning of that is hazy) because a
CRNG is Not Enough, my recommendation these days is that they get
something like an open hardware RNG solution, such as ChaosKey from
Altus Metrum[1].
[1] https://altusmetrum.org/ChaosKey/
- Ted
On Wed, Jul 18, 2018 at 05:29:58PM +0200, Yann Droneaud wrote:
> Sure, but, AFAICT, RDRAND is already in use through arch_get_random_*()
> functions when CONFIG_ARCH_RANDOM is enabled.
>
> From an outside PoV, there's a conflict: why one would want its kernel
> to use CPU hwrng if one has purposely disabled CONFIG_RANDOM_TRUST_CPU
> ?
Yes, but we use it to mix in RDRAND into the entropy pool. So we're
not depending solely on RDRAND's output. The trust model that we're
using is this. The presumption is that (at least for US-based CPU
manfacturers) the amount of effort needed to add a blatent backdoor
to, say, the instruction scheduler and register management file is
such that it couldn't be done by a single engineer, or even a very
small set of engineers. Enough people would need to know about it, or
would be able to figure out something untowards was happening, or it
would be obvious through various regression tests, that it would be
obvious if there was a generic back door in the CPU itself. This is a
good thing, because ultimately we *have* to trust the general purpose
CPU. If the CPU is actively conspiring against you, there really is
no hope.
However, the RDRAND unit is a small, self-contained thing, which is
*documented* to use an AES whitener (e.g., it does an AES encryption
as its last step). So presumably, a change to make the RDRAND unit
effectively be:
AES_ENCRYPT(NSA_KEY, COUNTER++)
Is much easier to hide or introduce.
So that's why people are comfortable using RDRAND mixed into the
output of the entropy pools. Yes, in theory, if the CPU has
backdoored the XOR instruction if it sees an RDRAND just before it,
you're sunk. But in if you don't trust the CPU to that level, you
should simply not be using that CPU at all. Period.
So personally, I probably would never chose to use a CPU that was
manufactured by a company owned or controlled by a PLA general or one
of Putin's Oligarchs. But I'm not going to tell other people what to
do; they should make their own decisions.
Now, there is one exception to this, and that is the CPU has RDRAND
support, it will use that exclusively for get_random_{u32, u64, int, long}.
But kernel code shouldn't be using this for cryptographic purposes. If you
need to generate a random key, you should be using get_random_bytes().
get_random_u32, et. al, are designed for things like stack canaries or
TCP sequence numbers.
Regards,
- Ted
Theodore Y. Ts'o <[email protected]> wrote:
> For those people who are super paranoid and want a "true
> random number generator" (and the meaning of that is hazy) because a
> CRNG is Not Enough, my recommendation these days is that they get
> something like an open hardware RNG solution, such as ChaosKey from
> Altus Metrum[1].
>
> [1] https://altusmetrum.org/ChaosKey/
Yes & one of those can also solve any difficulty with random(4) at
startup. Another alternative, perhaps easier on some systems, is
Denker's Turbid trng:
https://www.av8n.com/turbid/paper/turbid.htm
On 18 July 2018 at 18:21, Ken Moffat <[email protected]> wrote:
> On 18 July 2018 at 02:43, Theodore Ts'o <[email protected]> wrote:
>>
>> This will prevent getrandom(2) from blocking, if there is a
>> willingness to trust the CPU manufacturer.
> For me, it seems a price worth paying. I've got bigger problems than
> _worriying_ about my government, or yours, spying on me, so I'd like to take
> the risk.
>
Sadly, my enthusiasm was premature: the Kaveri doesn't have a hwrng. So
although I've enabled the device under the HW_RANDOM options, nothing
comes out and this "fix" will only work for some machines.
For me, I'll have to go to plan B (revise the bootscript and/or patch unbound).
I see that Nixos seems to bind /dev/urandom to /var/lib/unbound/dev/random
so I guess that ought to work. Sorry for the noise.
ĸen
On Wed, Jul 18, 2018 at 04:22:35PM -0400, Sandy Harris wrote:
>
> Yes & one of those can also solve any difficulty with random(4) at
> startup. Another alternative, perhaps easier on some systems, is
> Denker's Turbid trng:
> https://www.av8n.com/turbid/paper/turbid.htm
In the link above I saw breadboards with resistors plugged in,
alligator clips to TRG plugs, shield boxes with aluminum foil, and
doing calibrations using voltmeters. While that induced a pleasant
flashback to my junior high days when I experimented with electronics,
I'm not entirely sure most sysadmins would call that "easy". :-)
- Ted
Hi,
Le mercredi 18 juillet 2018 à 13:36 -0400, Theodore Y. Ts'o a écrit :
> For those people who are super paranoid and want a "true random
> number generator" (and the meaning of that is hazy) because a
> CRNG is Not Enough, my recommendation these days is that they get
> something like an open hardware RNG solution, such as ChaosKey from
> Altus Metrum[1].
>
> [1] https://altusmetrum.org/ChaosKey/
>
I could suggest "Infinite Noise" [1] keys which are also open hardware.
They use a different design, based on "modular multiplication" which
should be immune to most RF noise,
The original model is currently sold out[2] but a fork exists[3].
One can also have a look at OneRNG [4][5] which uses a more usual
design but adds a nice EMI shield protection.
[1] https://github.com/waywardgeek/infnoise
[2] https://www.tindie.com/products/WaywardGeek/infinite-noise-true-random-number-generator/
[3] https://www.tindie.com/products/manueldomke/infinite-noise-trng-true-random-number-generator/
[4] http://onerng.info/
[5] http://moonbaseotago.com/onerng/
Regards.
--
Yann Droneaud
OPTEYA
On 07/17/2018 06:43 PM, 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 <[email protected]>
> ---
>
> 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.
>
So I went to test this patch and was pleasantly surprised to find
that the hang from the degenerate case had been fixed in rawhide.
This means future Fedora versions should actually just boot properly.
That said, I do think this is a beneficial option to have available
because it actually fixes the underlying problem instead of hoping
nobody else decides to block early in the bootup process.
Thanks,
Laura
> 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;
> }
>
>
Hi!
On Wed 2018-07-18 10:26:25, Theodore Y. Ts'o wrote:
> On Wed, Jul 18, 2018 at 09:22:13AM +0200, Yann Droneaud wrote:
> >
> > The text message should explain this is only relevant during
> > initialization / early boot.
> >
> > The config option name should state this.
>
> There are other workarounds for hangs that happen after initialization
> / early boot, yes. They are of varying levels of quality / safely,
> but that's neither here nor there.
>
> However, enabling config option means that the CRNG will be
> initialized with potentially information available to the CPU
> manufacturer and/or Nation States, and this persists *after*
> initialization / early boot. So to say, "we're perfectly safe after
> we leave initialization / early boot" is not true.
This should really be explained in the help text.
I assume that after 10 seconds of moving mouse, user is safe even when
rdrand is backoored?
(Plus, I'd say this should be kernel command line optiom, not config
option...?)
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Aug 04, 2018 at 11:52:10PM +0200, Pavel Machek wrote:
> > However, enabling config option means that the CRNG will be
> > initialized with potentially information available to the CPU
> > manufacturer and/or Nation States, and this persists *after*
> > initialization / early boot. So to say, "we're perfectly safe after
> > we leave initialization / early boot" is not true.
>
> This should really be explained in the help text.
>
> I assume that after 10 seconds of moving mouse, user is safe even when
> rdrand is backoored?
You'll hate this answer, but "it depends". Suppose someone is using
an init script which generates ssh keys upon first boot if they are
missing. If this is the case, *and* RDRAND is backdoored, then the
keys will be generated in such a way that they *might* be succeptible
to being guessed by a nation state. Moving your mouse around for 1000
or 10,000 seconds won't help if the host's ssh keys has already been
generated.
Depending on your hardware, no mouse motion might be necessary at all.
On my laptop (a Dell XPS 13 model 9370) using an dm-crypt protected
root disk, and running a Debian testing userspace, with a 4.18-rc6
based kernel, the "CRNG is initialized" message is printed *before*
the root file system is mounted.
On other systems, where the hardware does not issue as many
interrupts, the mouse motion might be extremely important in order to
get the "CRNG is initialized" message.
> (Plus, I'd say this should be kernel command line option, not config
> option...?)
Agreed, there should be a command line option as well. I just haven't
gotten around to it yet, and in the meantime, having a config option
is better than nothing. Patches gratefully accepted... :-)
- Ted
On Sat, Aug 04, 2018 at 08:25:14PM -0400, Theodore Y. Ts'o wrote:
> Depending on your hardware, no mouse motion might be necessary at all.
> On my laptop (a Dell XPS 13 model 9370) using an dm-crypt protected
> root disk, and running a Debian testing userspace, with a 4.18-rc6
> based kernel, the "CRNG is initialized" message is printed *before*
> the root file system is mounted.
Sorry, correction. It's printed *before* the root file system is
remounted read/write. (Which means before we can generate long-term
public keys and save them to the file system.)
- Ted
On Sat 2018-08-04 20:25:14, Theodore Y. Ts'o wrote:
> On Sat, Aug 04, 2018 at 11:52:10PM +0200, Pavel Machek wrote:
> > > However, enabling config option means that the CRNG will be
> > > initialized with potentially information available to the CPU
> > > manufacturer and/or Nation States, and this persists *after*
> > > initialization / early boot. So to say, "we're perfectly safe after
> > > we leave initialization / early boot" is not true.
> >
> > This should really be explained in the help text.
> >
> > I assume that after 10 seconds of moving mouse, user is safe even when
> > rdrand is backoored?
>
> You'll hate this answer, but "it depends". Suppose someone is using
> an init script which generates ssh keys upon first boot if they are
> missing. If this is the case, *and* RDRAND is backdoored, then the
> keys will be generated in such a way that they *might* be succeptible
> to being guessed by a nation state. Moving your mouse around for 1000
> or 10,000 seconds won't help if the host's ssh keys has already been
> generated.
Yep, understood, but after moving the mouse, /dev/random &
/dev/urandom can be trusted afaict.
> Depending on your hardware, no mouse motion might be necessary at all.
> On my laptop (a Dell XPS 13 model 9370) using an dm-crypt protected
> root disk, and running a Debian testing userspace, with a 4.18-rc6
> based kernel, the "CRNG is initialized" message is printed *before*
> the root file system is mounted.
Entropy is easy to gather on any laptop. cat /dev/sda > /dev/null :-).
> On other systems, where the hardware does not issue as many
> interrupts, the mouse motion might be extremely important in order to
> get the "CRNG is initialized" message.
>
> > (Plus, I'd say this should be kernel command line option, not config
> > option...?)
>
> Agreed, there should be a command line option as well. I just haven't
> gotten around to it yet, and in the meantime, having a config option
> is better than nothing. Patches gratefully accepted... :-)
Well, this was RFC :-). I actually don't think config option is good
idea. Command line option is enough.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html