From: Kyle Moffett Subject: Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem Date: Fri, 6 Aug 2010 00:50:04 -0400 Message-ID: References: <23662.1281056463@redhat.com> <20100806011706.GA21657@gondor.apana.org.au> <20100806014057.GA22395@gondor.apana.org.au> <20100806023539.GA22774@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Herbert Xu , David Howells , gregkh@suse.de, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org To: Linus Torvalds Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:50471 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754675Ab0HFEu1 convert rfc822-to-8bit (ORCPT ); Fri, 6 Aug 2010 00:50:27 -0400 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: On Fri, Aug 6, 2010 at 00:20, Linus Torvalds wrote: > On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu wrote: >> Because it can save data. =C2=A0Each cryptographic algorithm (such a= s >> 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-d= o > 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