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 for Android: free password hash cracker in your pocket

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

Message-Id: <20200329202624.087251ba5c6d2d9715e5710f@gmail.com>
Date:   Sun, 29 Mar 2020 20:26:24 +0200
From:   Alexander Sverdlin <alexander.sverdlin@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
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

Hello Ted,

On Sun, 29 Mar 2020 12:56:24 -0400
"Theodore Y. Ts'o" <tytso@....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@...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().

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.