crypto: loongson - Select CRYPTO_RNG
Subsystems (3)
PATCH 1/1 crypto: loongson - Select CRYPTO_RNG
This driver registers a rng_alg, so it requires CRYPTO_RNG.
--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/crypto/loongson/Kconfig +1 -0
@@ -1,5 +1,6 @@ config CRYPTO_DEV_LOONGSON_RNG tristate "Support for Loongson RNG Driver" depends on MFD_LOONGSON_SE + select CRYPTO_RNG help Support for Loongson RNG Driver.
base-commit: 6c9dddeb582fde005360f4fe02c760d45ca05fb5
Signature · 1 line
2.54.0
Quoted 8 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>
Quoted 20 lines
--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)drivers/crypto/loongson/Kconfig +1
-0@@ -1,5 +1,6 @@ config CRYPTO_DEV_LOONGSON_RNG tristate "Support for Loongson RNG Driver" depends on MFD_LOONGSON_SE + select CRYPTO_RNG help Support for Loongson RNG Driver.base-commit:
6c9dddeb582fde005360f4fe02c760d45ca05fb5--
2.54.0
Quoted 14 lines · Huacai Chen
Quoted 8 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- 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 hwrng subsystem, but rather the pointless crypto_rng system which no one uses. So if it was intended to provide entropy for /dev/urandom etc., that isn't what it's doing.
Can we just delete this driver?
- Eric
Quoted 9 lines · Eric Biggers
Quoted 8 lines · Huacai Chen
Quoted 7 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>
Quoted 7 lines
Quoted 5 lines
Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- 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
Quoted 8 lines
hwrng subsystem, but rather the pointless
crypto_rngsystem which no one uses. So if it was intended to provide entropy for/dev/urandometc., that isn't what it's doing.Can we just delete this driver?
- Eric
Quoted 19 lines · Qunqin Zhao
Quoted 9 lines · Eric Biggers
Quoted 8 lines · Huacai Chen
Quoted 7 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>Quoted 7 lines
Quoted 5 lines
Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- 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
Quoted 6 lines
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)?
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.
- Eric
Quoted 34 lines · Eric Biggers
Quoted 15 lines · Qunqin Zhao
Quoted 14 lines · Eric Biggers
Quoted 13 lines · Huacai Chen
Quoted 7 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
Quoted 2 lines
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_ALGis a userspace interface; it's not available for in-kernel use. If you mean usingcrypto_rngdirectly, note that no kernel code actually uses it other than the tests, the implementation ofAF_ALG, and the FIPS-specific code which usesdrbg.cspecifically.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)?
Quoted 6 lines
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_ALGseems 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,
Qunqin
Quoted 2 lines
- Eric
Quoted 31 lines · Qunqin Zhao
Quoted 29 lines · Eric Biggers
Quoted 15 lines · Qunqin Zhao
Quoted 14 lines · Eric Biggers
Quoted 13 lines · Huacai Chen
Quoted 7 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
Quoted 2 lines
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_ALGis a userspace interface; it's not available for in-kernel use. If you mean usingcrypto_rngdirectly, note that no kernel code actually uses it other than the tests, the implementation ofAF_ALG, and the FIPS-specific code which usesdrbg.cspecifically.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 6 lines
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_ALGseems completely redundant for this case.
Quoted 7 lines
To be honest, I previously assumed that the
hw_randomwas designed strictly and exclusively for the TRNG mode.Is it architecturally acceptable or common practice for a PRNG mode to utilize
hw_randomas well?Thanks,
So the Loongson RNG is a PRNG? Where does it get its entropy from, and what is its security strength?
- Eric
Quoted 31 lines · Eric Biggers
Quoted 30 lines · Qunqin Zhao
Quoted 29 lines · Eric Biggers
Quoted 15 lines · Qunqin Zhao
Quoted 14 lines · Eric Biggers
Quoted 13 lines · Huacai Chen
Quoted 7 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>Reviewed-by Huacai Chen <[email protected]>Quoted 4 lines
--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)Quoted 8 lines
Quoted 2 lines
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_ALGis a userspace interface; it's not available for in-kernel use. If you mean usingcrypto_rngdirectly, note that no kernel code actually uses it other than the tests, the implementation ofAF_ALG, and the FIPS-specific code which usesdrbg.cspecifically.
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
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_ALGseems completely redundant for this case.To be honest, I previously assumed that the
hw_randomwas designed strictly and exclusively for the TRNG mode.
Quoted 6 lines
Quoted 4 lines
Is it architecturally acceptable or common practice for a PRNG mode to utilize
hw_randomas 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
Quoted 2 lines
- Eric
Quoted 6 lines · Qunqin Zhao
Quoted 6 lines
Quoted 6 lines
To be honest, I previously assumed that the
hw_randomwas designed strictly and exclusively for the TRNG mode.Is it architecturally acceptable or common practice for a PRNG mode to utilize
hw_randomas well?
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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.
That reseed function gets called with entropy from the Linux RNG. So, it seems it's really just a PRNG seeded from the Linux RNG. What value does that provide over just using the Linux RNG directly?
Quoted 2 lines
So the core issue here is whether a PRNG driver can utilize the crypto interface.
If you're asking about crypto_rng, it can. But the crypto_rng interface is also kind of useless. If you're asking about hwrng, it does look like it's designed for TRNGs. Would it be possible for this driver to use the TRNG mode?
Quoted 4 lines
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
Most of the drivers in drivers/crypto/ are added by the hardware manufacturer without any regard for whether they're useful or not.
- Eric
Quoted 10 lines · Eric Biggers
Quoted 9 lines · Qunqin Zhao
Quoted 9 lines
Quoted 7 lines
To be honest, I previously assumed that the
hw_randomwas designed strictly and exclusively for the TRNG mode.Is it architecturally acceptable or common practice for a PRNG mode to utilize
hw_randomas well?Thanks,
So the Loongson RNG is a PRNG? Where does it get its entropy from, and what is its security strength?
Quoted 7 lines
Quoted 4 lines
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.That reseed function gets called with entropy from the Linux RNG. So, it seems it's really just a PRNG seeded from the Linux RNG. What value does that provide over just using the Linux RNG directly?
Alternatively,the reseed function can serve as a stirring mechanism, where the primary entropy comes from the internal hardware TRNG.
Or simply ignore the entropy from the Linux RNG entirely, trigger a reseeding internal.
The driver merely forwards the seed to the firmware; how it is utilized and what kind of random numbers are returned are entirely determined by the firmware implementation.
Quoted 7 lines
Quoted 3 lines
So the core issue here is whether a PRNG driver can utilize the crypto interface.
If you're asking about
crypto_rng, it can. But thecrypto_rnginterface is also kind of useless. If you're asking about hwrng, it does look like it's designed for TRNGs. Would it be possible for this driver to use the TRNG mode?
I mean crypto_rng.
We might use the hwrng interface to add support for the TRNG in this driver.
Quoted 7 lines
Quoted 5 lines
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_rngMost of the drivers in
drivers/crypto/are added by the hardware manufacturer without any regard for whether they're useful or not.
If we are dropping crypto-rng drivers entirely,
I am fine with removing the Loongson driver along with the others.
However, targeting the Loongson driver alone is unacceptable.
Thanks,
Qunqin.
Quoted 2 lines
- Eric
Quoted 34 lines · Qunqin Zhao
Quoted 10 lines · Eric Biggers
Quoted 9 lines · Qunqin Zhao
Quoted 9 lines
Quoted 7 lines
To be honest, I previously assumed that the
hw_randomwas designed strictly and exclusively for the TRNG mode.Is it architecturally acceptable or common practice for a PRNG mode to utilize
hw_randomas well?Thanks,
So the Loongson RNG is a PRNG? Where does it get its entropy from, and what is its security strength?
Quoted 7 lines
Quoted 4 lines
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.That reseed function gets called with entropy from the Linux RNG. So, it seems it's really just a PRNG seeded from the Linux RNG. What value does that provide over just using the Linux RNG directly?
Alternatively,the reseed function can serve as a stirring mechanism, where the primary entropy comes from the internal hardware TRNG.
Or simply ignore the entropy from the Linux RNG entirely, trigger a reseeding internal.
The driver merely forwards the seed to the firmware; how it is utilized and what kind of random numbers are returned are entirely determined by the firmware implementation.
Quoted 3 lines
Quoted 3 lines
So the core issue here is whether a PRNG driver can utilize the crypto interface.
Quoted 8 lines
Quoted 4 lines
If you're asking about
crypto_rng, it can. But thecrypto_rnginterface is also kind of useless. If you're asking about hwrng, it does look like it's designed for TRNGs. Would it be possible for this driver to use the TRNG mode?I mean
crypto_rng.We might use the hwrng interface to add support for the TRNG in this driver.
If you can actually provide fresh entropy on each call, then yes you should implement hwrng.
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
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_rngMost of the drivers in
drivers/crypto/are added by the hardware manufacturer without any regard for whether they're useful or not.If we are dropping crypto-rng drivers entirely,
We should, since they have no real point.
Quoted 3 lines
I am fine with removing the Loongson driver along with the others.
However, targeting the Loongson driver alone is unacceptable.
We just happen to be digging into the details on this driver right now, since we're having to spend time fixing it. Thanks for confirming that this is supported purely for parity with other drivers.
- Eric
Herbert Xu
maintainerQuoted 10 lines · Eric Biggers
This driver registers a
rng_alg, so it requiresCRYPTO_RNG.Fixes 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")Reported-by kernel test robot <[email protected]>Signed-off-by Eric Biggers <[email protected]>--- drivers/crypto/loongson/Kconfig | 1 + 1 file changed, 1 insertion(+)
Patch applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt