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]

Message-ID: <20100806023539.GA22774@gondor.apana.org.au>
Date:	Fri, 6 Aug 2010 10:35:39 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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 Thu, Aug 05, 2010 at 07:01:21PM -0700, Linus Torvalds wrote:
> On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu <herbert@...dor.hengli.com.au> wrote:
> >
> > -config CRYPTO_MANAGER_TESTS
> > -       bool "Run algolithms' self-tests"
> > -       default y
> > -       depends on CRYPTO_MANAGER2
> > +config CRYPTO_MANAGER_DISABLE_TESTS
> > +       bool "Disable run-time self tests"
> > +       depends on CRYPTO_MANAGER2 && EMBEDDED
> 
> Why do you still want to force-enable those tests? I was going to
> complain about the "default y" anyway, now I'm _really_ complaining,
> because you've now made it impossible to disable those tests. Why?

Because it can save data.  Each cryptographic algorithm (such as
AES) may have multiple impelmentations, some of which are hardware-
based.

The purpose of these tests are to make a particular driver or
implementation available only if it passes them.  So your encrypted
disk/file system will not be subject to a hardware/software combo
without at least some semblance of testing.

The last thing you want to is to upgrade your kernel with a new
hardware crypto driver that detects that you have a piece of rarely-
used crypto hardeware, decides to use it and ends up making your
data toast.

But whatever, if you want the default to be no tests, that's fine.
Here's the patch to do just that.

commit 00ca28a507b215dcd121735f16764ea4173c4ff9
Author: Herbert Xu <herbert@...dor.apana.org.au>
Date:   Fri Aug 6 10:34:00 2010 +0800

    crypto: testmgr - Default to no tests
    
    On Thu, Aug 05, 2010 at 07:01:21PM -0700, Linus Torvalds wrote:
    > On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu <herbert@...dor.hengli.com.au> wrote:
    > >
    > > -config CRYPTO_MANAGER_TESTS
    > > -       bool "Run algolithms' self-tests"
    > > -       default y
    > > -       depends on CRYPTO_MANAGER2
    > > +config CRYPTO_MANAGER_DISABLE_TESTS
    > > +       bool "Disable run-time self tests"
    > > +       depends on CRYPTO_MANAGER2 && EMBEDDED
    >
    > Why do you still want to force-enable those tests? I was going to
    > complain about the "default y" anyway, now I'm _really_ complaining,
    > because you've now made it impossible to disable those tests. Why?
    
    As requested, this patch sets the default to y and removes the
    EMBEDDED dependency.
    
    Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 6f5c50f..e573077 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -103,7 +103,8 @@ config CRYPTO_MANAGER2
 
 config CRYPTO_MANAGER_DISABLE_TESTS
 	bool "Disable run-time self tests"
-	depends on CRYPTO_MANAGER2 && EMBEDDED
+	default y
+	depends on CRYPTO_MANAGER2
 	help
 	  Disable run-time self tests that normally take place at
 	  algorithm registration.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/