linux-kernel - Re: [PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200329165624.GO53396@mit.edu>
Date:   Sun, 29 Mar 2020 12:56:24 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Alexander Sverdlin <alexander.sverdlin@...il.com>
Cc:     linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] random: Drop ARCH limitations for CONFIG_RANDOM_TRUST_CPU

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@...il.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