On Fri, Aug 6, 2010 at 00:20, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx> wrote: >> Because it can save data. Each cryptographic algorithm (such as >> AES) may have multiple impelmentations, some of which are hardware- >> based. > > Umm. The _developer_ had better test the thing. That is absolutely > _zero_ excuse for then forcing every boot for every poor user to re-do > the test over and over again. > > Guys, this comes up every single time: you as a developer may think > that your code is really important, but get over yourself already. > It's not so important that everybody must be forced to do it. Speaking as a user whose been bitten several times by bad crypto implementations, I'd personally rather have this testing on by default (if the crypto API it depends on is on). It's pretty damn inexpensive to do a few brief crypto operations during initialization as a quick smoke test. We already do something somewhat similar when loading the RAID5/RAID6 driver, although admittedly that's a speed-test for picking an optimized algorithm. You should also realize that crypto drivers are very much *NOT* in the same situation as most other drivers. Without this test, adding a new crypto hardware driver to the kernel is a completely unsafe operation, because it could completely break users setups. You have previously said you're fine accepting new drivers even after the initial merge window because they can't break anything, but in crypto that's not true. I've actually had it trigger in exactly the described situation. I had a box with an encrypted filesystem that I downloaded a new distro kernel on with new drivers. The new kernel included a bunch of new "EXPERIMENTAL" drivers for hardware, none of which I thought I cared about until I noticed in "dmesg" that one of them was getting enabled and then failing tests. So there are unique and compelling reasons for default-enabled basic smoke tests of cryptographic support during boot. To be honest, the test and integration engineer in me would like it if there were more intensive in-kernel POST tests that could be enabled by a kernel parameter or something for high-reliability embedded devices. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
