Re: [PATCH] crypto: loongson - Select CRYPTO_RNG

[Qunqin Zhao]

在 2026/5/23 上午1:48, Eric Biggers 写道:
> On Fri, May 22, 2026 at 02:40:38PM +0800, Qunqin Zhao wrote:
> > 在 2026/5/22 下午12:03, Eric Biggers 写道:
> > > On Fri, May 22, 2026 at 11:41:15AM +0800, Qunqin Zhao wrote:
> > > > 在 2026/5/22 上午10:57, Eric Biggers 写道:
> > > > > On Fri, May 22, 2026 at 10:52:42AM +0800, Huacai Chen wrote:
> > > > > > On Fri, May 22, 2026 at 10:26 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > > > > > > This driver registers a rng_alg, so it requires CRYPTO_RNG.
> > > > > > >
> > > > > > > Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
> > > > > > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > > > > > Closes: https://lore.kernel.org/oe-kbuild-all/202605201622.qWOiiZTV-lkp@xxxxxxxxx/
> > > > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> > > > > > Reviewed-by: Huacai Chen <chenhuacai@xxxxxxxxxxx>
> > > > > > > ---
> > > > > > >     drivers/crypto/loongson/Kconfig | 1 +
> > > > > > >     1 file changed, 1 insertion(+)
> > > > > By the way, do any of the loongson people have any comment on what they
> > > > > think the point of this driver is?  It's not registered with the actual
> > > > To provide an AF_ALG-based random number generation interface for other
> > > > modules and user-space programs.
> > > >
> > > > Thanks,
> > > >
> > > > Qunqin
> > > AF_ALG is a userspace interface; it's not available for in-kernel use.
> > > If you mean using crypto_rng directly, note that no kernel code actually
> > > uses it other than the tests, the implementation of AF_ALG, and the
> > > FIPS-specific code which uses drbg.c specifically.
> > >
> > > So, the first half of your justification doesn't make any sense.
> > >
> > > As far as the second half: why would a userspace program do that instead
> > > of just using the regular Linux RNG (/dev/urandom)?
> Could you answer this question?  If there's no answer to this question,
> then there's no use case for this driver as-is.

While I'm not an expert on the specific application scenarios for these,

I believe any PRNG driver should utilize the crypto_rng subsystem.

> > > AFAIK, the only reason to use a HW RNG directly is for certification
> > > reasons.
> > >
> > > However, there's also already an interface for that: /dev/hw_random.
> > >
> > > So AF_ALG seems completely redundant for this case.
> > To be honest, I previously assumed that the `hw_random` was designed
> > strictly and exclusively for the TRNG mode.
> >
> > Is it architecturally acceptable or common practice for a PRNG mode to
> > utilize `hw_random` as well?
> >
> > Thanks,
> So the Loongson RNG is a PRNG?  Where does it get its entropy from, and
> what is its security strength?

Loongson's hardware supports both TRNG and PRNG simultaneously.

We can locate a reseed function within loongson-rng.c, which clearly 
indicates that it is a PRNG driver.


So the core issue here is whether a PRNG driver can utilize the crypto 
interface.

If it cannot, does that imply the drivers listed below serve no 
practical purpose? (7.1-rc1)

loongson@loongson:~/upstream/linux/drivers/crypto$ grep 
crypto_register_rng -r *
allwinner/sun8i-ss/sun8i-ss-core.c:            err = 
crypto_register_rng(&ss_algs[i].alg.rng);
allwinner/sun8i-ce/sun8i-ce-core.c:            err = 
crypto_register_rng(&ce_algs[i].alg.rng);
allwinner/sun4i-ss/sun4i-ss-core.c:            err = 
crypto_register_rng(&ss_algs[i].alg.rng);
amcc/crypto4xx_core.c:            rc = crypto_register_rng(&alg->alg.u.rng);
caam/caamprng.c:    ret = crypto_register_rng(&caam_prng_alg.rng);
exynos-rng.c:    ret = crypto_register_rng(&exynos_rng_alg);
hisilicon/trng/trng.c:        ret = crypto_register_rng(&hisi_trng_alg);
loongson/loongson-rng.c:        ret = 
crypto_register_rng(&loongson_rng_alg);
qcom-rng.c:    ret = crypto_register_rng(&qcom_rng_alg);
xilinx/xilinx-trng.c:    ret = crypto_register_rng(&xtrng_trng_alg);


Thanks,

Qunqin

> - Eric