linux-kernel - Re: Crypto Update for 4.2

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: <20150624132937.GA32020@gondor.apana.org.au>
Date:	Wed, 24 Jun 2015 21:29:37 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Crypto Update for 4.2

On Tue, Jun 23, 2015 at 07:11:19PM -0700, Linus Torvalds wrote:
> On Mon, Jun 22, 2015 at 1:44 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> >
> > Here is the crypto update for 4.2:
> 
> Hmm. I noticed a new annoyance:
> 
> I get this at bootup:
> 
>   [  +0.001504] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)

This is indeed bogus and I'll make sure it disappears.

>   [  +0.002233] alg: aead: setkey failed on test 1 for
> rfc4106-gcm-aesni: flags=0

This however is a real bug.  It looks like aesni is somehow broken
and is failing on setkey.  I'll look into it.

> in general, I'm not at all convinced that the crypto tests make sense.
> I absolutely destest that horrid "testmgr.h" file that is 32
> _thousand_ lines of noise. And now it's apparently complaining about a
> missing test, so that nasty mess will presumably grow.
> 
> Could you not make the test infrastructure be something that gets run
> in user space?

I too think the current testmgr model has reached its limit.
However, it has been quite useful in catching bugs like the
one you saw which may otherwise result in hard-to-track-down
bugs in other subsystems such as IPsec or disk encryption.

What I was planning to do is to instead bundle the test vectors
with the algorithms themselves.  So for each algorithm we would
have the test vectors in the canonical C implementation which then
would be used to test every other implmenetation of that algorithm.

The test code could similarly be distributed out to the individual
types, e.g., RNG tests would go into rng.c, hash tests into ahash.c,
etc.

When this is done there would be no central repository of testing
information anymore.

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/