Re: [PATCH 3/4] crypto: qcom-rng - Remove crypto_rng interface

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jun 04, 2026 at 10:20:38AM +0530, Neeraj Soni wrote:
> On 5/30/2026 7:33 AM, Eric Biggers wrote:
> > qcom-rng.c exposes the same hardware through two completely separate
> > interfaces, crypto_rng and hwrng.  However, the implementation of this
> > is buggy because it permits generation operations from these interfaces
> > to run concurrently with each other, accessing the same registers.  That
> > is, qcom_rng_generate() synchronizes with itself but not with
> > qcom_hwrng_read().  This results in potential repetition of output from
> > the RNG, output of non-random values, etc.
> > 
> > Fortunately, there's actually no point in hardware RNG drivers
> > implementing the crypto_rng interface.  It's not actually used by
> > anything besides the "rng" algorithm type of AF_ALG, which in turn is
> > not actually used in practice.  Other crypto_rng hardware drivers are
> 
> How it was established that there are no active users/clints for qcom-rng
> using crypto_rng interface? If there is no concrete way to do then this
> patch breaks backward compatibility.

The only in-kernel user of crypto_rng uses it to access
"drbg_nopr_hmac_sha512" on "FIPS-enabled" systems.  So, the only
possibility for a user of "qcom-rng" would be userspace via AF_ALG.  But
I've never heard of that being done.  It would be a really odd and
pointless thing to do when the much easier to use UAPIs /dev/random and
/dev/hwrng already exist.  And broken too, as I pointed out.

AF_ALG as a whole is rarely used and is a mistake.  It exposes a massive
amount of unused and broken functionality to userspace, including every
single implementation of every single crypto algorithm by name, which
never should have been done in the way it was.  We don't have much
choice but to continue removing algorithms/drivers from it to keep Linux
maintainable, as has already been happening successfully for many years.

The AF_ALG hardware RNG support is especially pointless, given the
redundancy with /dev/random and /dev/hwrng.  As far as I can tell the
main purpose of it is just to confuse RNG driver authors into thinking
that they are making Linux utilize their RNG.

Keep in mind that for AF_ALG there's also a compatibility trick
available to be implemented if it ever needs to: the kernel could
automatically remap requests for a particular driver name, like
"qcom-rng", to a different one like "drbg_nopr_hmac_sha512".

However, it's never actually been necessary to use that trick in *any*
of the times that crypto drivers have been removed or renamed.  No one
has ever cared.  There's some AF_ALG functionality we know that a few
programs use, but this isn't part of that.

So I think we can be quite confident in proceeding with this patch even
without proactively putting in the name remapping.

- Eric