[PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

[PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

[Alexander Sverdlin]

The option itself looks attractive for the embedded devices which often
have HWRNG but less entropy from user-input. And these devices are often
ARM/ARM64 or MIPS. The reason to limit it to X86/S390/PPC is not obvious.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
 drivers/char/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 26956c006987..abc874722251 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -539,7 +539,6 @@ endmenu
 
 config RANDOM_TRUST_CPU
 	bool "Trust the CPU manufacturer to initialize Linux's CRNG"
-	depends on X86 || S390 || PPC
 	default n
 	help
 	Assume that CPU manufacturer (e.g., Intel or AMD for RDSEED or
-- 
2.25.1

Re: [PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

[Theodore Y. Ts'o]

On Sun, Mar 29, 2020 at 10:29:09AM +0200, Alexander Sverdlin wrote:
> The option itself looks attractive for the embedded devices which often
> have HWRNG but less entropy from user-input. And these devices are often
> ARM/ARM64 or MIPS. The reason to limit it to X86/S390/PPC is not obvious.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>

This feature is *only* applicable if the CPU supports a
arch_get_random_seed_long() or arch_get_random_long().  I believe
there are some server-class ARM64 CPU's that support such an
instruction, but I don't believe any of the embedded arm64 --- and
certainly non of the embedded arm --- SOC's support
arch_get_random_long().

The reason why we limited it to X86/S390/PPC is because those were the
platforms which supported an RDRAND-like instruction at the time.
Richard Henderson added support for ARM64 in commit 1a50ec0b3b2e
("arm64: Implement archrandom.h for ARMv8.5-RNG") in late January 2020.

So we should either add ARM64 to the dependency list, or we could, as
you suggest, simply remove the dependency altogether.  The tradeoff is
that it will cause an extra CONFIG prompt on a number of platforms
(mips, arm, sparc, etc.) where it will be utterly pointless since
those architectures have no chance of support a RDRAND-like
instruction.

Cheers,

						- Ted

Re: [PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

[Alexander Sverdlin]

Hello Ted,

On Sun, 29 Mar 2020 12:56:24 -0400
"Theodore Y. Ts'o" <tytso@mit.edu> wrote:

> On Sun, Mar 29, 2020 at 10:29:09AM +0200, Alexander Sverdlin wrote:
> > The option itself looks attractive for the embedded devices which often
> > have HWRNG but less entropy from user-input. And these devices are often
> > ARM/ARM64 or MIPS. The reason to limit it to X86/S390/PPC is not obvious.
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> 
> This feature is *only* applicable if the CPU supports a
> arch_get_random_seed_long() or arch_get_random_long().  I believe
> there are some server-class ARM64 CPU's that support such an
> instruction, but I don't believe any of the embedded arm64 --- and
> certainly non of the embedded arm --- SOC's support
> arch_get_random_long().

you are right! Thank you for the explanation!
I totally missed the fact that it's not connected to hwrng drivers...
Please ignore the patch.

[...]

> So we should either add ARM64 to the dependency list, or we could, as
> you suggest, simply remove the dependency altogether.  The tradeoff is
> that it will cause an extra CONFIG prompt on a number of platforms
> (mips, arm, sparc, etc.) where it will be utterly pointless since
> those architectures have no chance of support a RDRAND-like
> instruction.

-- 
Alexander Sverdlin.

Re: [PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

[Mark Rutland]

On Sun, Mar 29, 2020 at 12:56:24PM -0400, Theodore Y. Ts'o wrote:
> On Sun, Mar 29, 2020 at 10:29:09AM +0200, Alexander Sverdlin wrote:
> > The option itself looks attractive for the embedded devices which often
> > have HWRNG but less entropy from user-input. And these devices are often
> > ARM/ARM64 or MIPS. The reason to limit it to X86/S390/PPC is not obvious.
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> 
> This feature is *only* applicable if the CPU supports a
> arch_get_random_seed_long() or arch_get_random_long().  I believe
> there are some server-class ARM64 CPU's that support such an
> instruction, but I don't believe any of the embedded arm64 --- and
> certainly non of the embedded arm --- SOC's support
> arch_get_random_long().
> 
> The reason why we limited it to X86/S390/PPC is because those were the
> platforms which supported an RDRAND-like instruction at the time.
> Richard Henderson added support for ARM64 in commit 1a50ec0b3b2e
> ("arm64: Implement archrandom.h for ARMv8.5-RNG") in late January 2020.
> 
> So we should either add ARM64 to the dependency list, or we could, as
> you suggest, simply remove the dependency altogether.  The tradeoff is
> that it will cause an extra CONFIG prompt on a number of platforms
> (mips, arm, sparc, etc.) where it will be utterly pointless since
> those architectures have no chance of support a RDRAND-like
> instruction.

Just for anyone watching, the dependency rework is already handled in
linux-next by commit:

  23ae0c17b89cfeb5 ("random: Make RANDOM_TRUST_CPU depend on ARCH_RANDOM")
  
... where x86, s390, ppc, and arm64 all select ARCH_RANDOM.

Mark.