linux-kernel - Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Aug 2010 00:50:04 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Herbert Xu <herbert@...dor.hengli.com.au>,
	David Howells <dhowells@...hat.com>, gregkh@...e.de,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr 
	problem

On Fri, Aug 6, 2010 at 00:20, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu <herbert@...dor.hengli.com.au> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/