On Wed Jun 11, 2025 at 9:04 PM CEST, Eric Biggers wrote: > On Wed, Jun 11, 2025 at 08:53:17PM +0200, Diederik de Haas wrote: >> I was about to respond to your reply, but I guess this may be a better >> fit for it. The TL;DR: version is this: >> >> If you think distros shouldn't enable it, as you initially clearly >> described and it seems to me you still think so, the right thing for >> distros to do, is to disable those test. Which in turn means the fast >> tests should not be reinstated (?). > > I mean, not enabling the tests in production is how it should be. > > But Fedora already enabled CRYPTO_SELFTESTS, apparently because of FIPS > (https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3886). That is recent and there's at least 1 person I recognize as having proper expertise in this matter ;-) > You're right there doesn't seem to be an up-to-date bug for Debian > (https://bugs.debian.org/599441 is old), so maybe my conclusion is premature. > > However, besides FIPS I think the problem is that the crypto/ philosophy is to Another problem (IMO) is that a lot (?) of people (like myself) don't (really) understand crypto and therefor rely on the description in the Kconfig help text and make a choice based on that. That's (one of) the reason(s) I was so happy with the clear text :-) > throw untested and broken hardware drivers over the wall at users. As long as Only speaking for myself, my *assumption* is that crypto functionality in hardware is/should be faster and would lessen the load on the CPU (which with several SBCs seems really worthwhile). But I don't have the knowledge to determine whether it's broken or not. Unless there's a(n easy) tool for that (like 'rngtest' [1]). [1] https://lore.kernel.org/linux-rockchip/6425788.NZdkxuyfQg@bagend/ resulting in f.e. 5afdb98dcc55 ("arm64: dts: rockchip: Describe why is HWRNG disabled in RK356x base dtsi") > that's the case, the self-tests do actually have some value in protecting users > from those drivers, even though that's not how it should be. Thanks for the additional info :-) Diederik