2019-05-29 16:57:49 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
x86, random: Architectural inlines to get random integers with RDRAND
Architectural inlines to get random ints and longs using the RDRAND
instruction.
Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware. This enables RDRAND to be used directly, bypassing the
kernel random number pool.
For technical documentation, see:
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
In this patch, this is *only* used for the nonblocking random number
pool. RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random. The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.
Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.
The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Originally-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Theodore Ts'o" <tytso@mit.edu>
2011-07-31 13:59:29 -07:00
|
|
|
/*
|
|
|
|
|
* This file is part of the Linux kernel.
|
|
|
|
|
*
|
2014-03-17 16:36:27 -07:00
|
|
|
* Copyright (c) 2011-2014, Intel Corporation
|
x86, random: Architectural inlines to get random integers with RDRAND
Architectural inlines to get random ints and longs using the RDRAND
instruction.
Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware. This enables RDRAND to be used directly, bypassing the
kernel random number pool.
For technical documentation, see:
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
In this patch, this is *only* used for the nonblocking random number
pool. RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random. The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.
Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.
The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Originally-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Theodore Ts'o" <tytso@mit.edu>
2011-07-31 13:59:29 -07:00
|
|
|
* Authors: Fenghua Yu <fenghua.yu@intel.com>,
|
|
|
|
|
* H. Peter Anvin <hpa@linux.intel.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef ASM_X86_ARCHRANDOM_H
|
|
|
|
|
#define ASM_X86_ARCHRANDOM_H
|
|
|
|
|
|
|
|
|
|
#include <asm/processor.h>
|
|
|
|
|
#include <asm/cpufeature.h>
|
|
|
|
|
|
|
|
|
|
#define RDRAND_RETRY_LOOPS 10
|
|
|
|
|
|
2016-06-08 12:38:46 -07:00
|
|
|
/* Unconditional execution of RDRAND and RDSEED */
|
x86, random: Architectural inlines to get random integers with RDRAND
Architectural inlines to get random ints and longs using the RDRAND
instruction.
Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware. This enables RDRAND to be used directly, bypassing the
kernel random number pool.
For technical documentation, see:
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
In this patch, this is *only* used for the nonblocking random number
pool. RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random. The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.
Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.
The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Originally-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Theodore Ts'o" <tytso@mit.edu>
2011-07-31 13:59:29 -07:00
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check rdrand_long(unsigned long *v)
|
2013-10-10 17:18:15 -07:00
|
|
|
{
|
2016-06-08 12:38:46 -07:00
|
|
|
bool ok;
|
|
|
|
|
unsigned int retry = RDRAND_RETRY_LOOPS;
|
|
|
|
|
do {
|
2020-05-08 12:58:17 +02:00
|
|
|
asm volatile("rdrand %[out]"
|
2016-06-08 12:38:46 -07:00
|
|
|
CC_SET(c)
|
2020-05-08 12:58:17 +02:00
|
|
|
: CC_OUT(c) (ok), [out] "=r" (*v));
|
2016-06-08 12:38:46 -07:00
|
|
|
if (ok)
|
|
|
|
|
return true;
|
|
|
|
|
} while (--retry);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check rdrand_int(unsigned int *v)
|
2016-06-08 12:38:46 -07:00
|
|
|
{
|
|
|
|
|
bool ok;
|
|
|
|
|
unsigned int retry = RDRAND_RETRY_LOOPS;
|
|
|
|
|
do {
|
2020-05-08 12:58:17 +02:00
|
|
|
asm volatile("rdrand %[out]"
|
2016-06-08 12:38:46 -07:00
|
|
|
CC_SET(c)
|
2020-05-08 12:58:17 +02:00
|
|
|
: CC_OUT(c) (ok), [out] "=r" (*v));
|
2016-06-08 12:38:46 -07:00
|
|
|
if (ok)
|
|
|
|
|
return true;
|
|
|
|
|
} while (--retry);
|
|
|
|
|
return false;
|
2013-10-10 17:18:15 -07:00
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check rdseed_long(unsigned long *v)
|
2014-03-17 16:36:27 -07:00
|
|
|
{
|
2016-06-08 12:38:38 -07:00
|
|
|
bool ok;
|
2020-05-08 12:58:17 +02:00
|
|
|
asm volatile("rdseed %[out]"
|
2016-06-08 12:38:46 -07:00
|
|
|
CC_SET(c)
|
2020-05-08 12:58:17 +02:00
|
|
|
: CC_OUT(c) (ok), [out] "=r" (*v));
|
2014-03-17 16:36:27 -07:00
|
|
|
return ok;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check rdseed_int(unsigned int *v)
|
2016-06-08 12:38:46 -07:00
|
|
|
{
|
|
|
|
|
bool ok;
|
2020-05-08 12:58:17 +02:00
|
|
|
asm volatile("rdseed %[out]"
|
2016-06-08 12:38:46 -07:00
|
|
|
CC_SET(c)
|
2020-05-08 12:58:17 +02:00
|
|
|
: CC_OUT(c) (ok), [out] "=r" (*v));
|
2016-06-08 12:38:46 -07:00
|
|
|
return ok;
|
2014-03-17 16:36:27 -07:00
|
|
|
}
|
|
|
|
|
|
2016-06-08 12:38:46 -07:00
|
|
|
/*
|
|
|
|
|
* These are the generic interfaces; they must not be declared if the
|
random: remove CONFIG_ARCH_RANDOM
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed RNG, using RDRAND
values alone won't harm anything, even if the outputs are malicious.
Rather, the issue is whether those values are being *trusted* to be good
or not. And so a new set of options were introduced as the real
ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
With these options, RDRAND is used, but it's not always credited. So in
the worst case, it does nothing, and in the best case, maybe it helps.
Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
center and became something certain platforms force-select.
The old options don't really help with much, and it's a bit odd to have
special handling for these instructions when the kernel can deal fine
with the existence or untrusted existence or broken existence or
non-existence of that CPU capability.
Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
ordinary asm-generic fallback pattern instead, keeping the two options
that are actually used. For now it leaves "nordrand" for now, as the
removal of that will take a different route.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-07-05 20:48:41 +02:00
|
|
|
* stubs in <linux/random.h> are to be invoked.
|
2016-06-08 12:38:46 -07:00
|
|
|
*/
|
2013-10-10 17:18:15 -07:00
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check arch_get_random_long(unsigned long *v)
|
2013-10-10 17:18:15 -07:00
|
|
|
{
|
2020-01-10 14:54:13 +00:00
|
|
|
return static_cpu_has(X86_FEATURE_RDRAND) ? rdrand_long(v) : false;
|
2013-10-10 17:18:15 -07:00
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check arch_get_random_int(unsigned int *v)
|
2014-03-17 16:36:27 -07:00
|
|
|
{
|
2020-01-10 14:54:13 +00:00
|
|
|
return static_cpu_has(X86_FEATURE_RDRAND) ? rdrand_int(v) : false;
|
2014-03-17 16:36:27 -07:00
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
|
2016-06-08 12:38:46 -07:00
|
|
|
{
|
2020-01-10 14:54:13 +00:00
|
|
|
return static_cpu_has(X86_FEATURE_RDSEED) ? rdseed_long(v) : false;
|
2016-06-08 12:38:46 -07:00
|
|
|
}
|
|
|
|
|
|
2020-01-10 14:54:19 +00:00
|
|
|
static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
|
2016-06-08 12:38:46 -07:00
|
|
|
{
|
2020-01-10 14:54:13 +00:00
|
|
|
return static_cpu_has(X86_FEATURE_RDSEED) ? rdseed_int(v) : false;
|
2016-06-08 12:38:46 -07:00
|
|
|
}
|
x86, random: Architectural inlines to get random integers with RDRAND
Architectural inlines to get random ints and longs using the RDRAND
instruction.
Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware. This enables RDRAND to be used directly, bypassing the
kernel random number pool.
For technical documentation, see:
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
In this patch, this is *only* used for the nonblocking random number
pool. RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random. The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.
Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.
The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Originally-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Theodore Ts'o" <tytso@mit.edu>
2011-07-31 13:59:29 -07:00
|
|
|
|
random: remove CONFIG_ARCH_RANDOM
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed RNG, using RDRAND
values alone won't harm anything, even if the outputs are malicious.
Rather, the issue is whether those values are being *trusted* to be good
or not. And so a new set of options were introduced as the real
ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
With these options, RDRAND is used, but it's not always credited. So in
the worst case, it does nothing, and in the best case, maybe it helps.
Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
center and became something certain platforms force-select.
The old options don't really help with much, and it's a bit odd to have
special handling for these instructions when the kernel can deal fine
with the existence or untrusted existence or broken existence or
non-existence of that CPU capability.
Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
ordinary asm-generic fallback pattern instead, keeping the two options
that are actually used. For now it leaves "nordrand" for now, as the
removal of that will take a different route.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-07-05 20:48:41 +02:00
|
|
|
#ifndef CONFIG_UML
|
|
|
|
|
void x86_init_rdrand(struct cpuinfo_x86 *c);
|
|
|
|
|
#endif
|
2016-06-08 12:38:46 -07:00
|
|
|
|
x86, random: Architectural inlines to get random integers with RDRAND
Architectural inlines to get random ints and longs using the RDRAND
instruction.
Intel has introduced a new RDRAND instruction, a Digital Random Number
Generator (DRNG), which is functionally an high bandwidth entropy
source, cryptographic whitener, and integrity monitor all built into
hardware. This enables RDRAND to be used directly, bypassing the
kernel random number pool.
For technical documentation, see:
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
In this patch, this is *only* used for the nonblocking random number
pool. RDRAND is a nonblocking source, similar to our /dev/urandom,
and is therefore not a direct replacement for /dev/random. The
architectural hooks presented in the previous patch only feed the
kernel internal users, which only use the nonblocking pool, and so
this is not a problem.
Since this instruction is available in userspace, there is no reason
to have a /dev/hw_rng device driver for the purpose of feeding rngd.
This is especially so since RDRAND is a nonblocking source, and needs
additional whitening and reduction (see the above technical
documentation for details) in order to be of "pure entropy source"
quality.
The CONFIG_EXPERT compile-time option can be used to disable this use
of RDRAND.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Originally-by: Fenghua Yu <fenghua.yu@intel.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Theodore Ts'o" <tytso@mit.edu>
2011-07-31 13:59:29 -07:00
|
|
|
#endif /* ASM_X86_ARCHRANDOM_H */
|
