linux-kernel - Re: [PATCH] crypto: tcrypt: add option to not exit on success

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:	Wed, 13 May 2009 07:08:26 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Jarod Wilson <jarod@...hat.com>, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: tcrypt: add option to not exit on success

On Wed, May 13, 2009 at 11:30:50AM +1000, Herbert Xu wrote:
> On Tue, May 12, 2009 at 08:37:27PM -0400, Neil Horman wrote:
> >
> > > Would there be any objections to dropping the noexit parameter
> > > entirely and just making its behavior the default? It would make
> > > all users regardless of fips mode notice failures more readily.
> > > 
> > I think thats a fine idea.  Theres no reason that a user of the tcrypt module
> > can't manually rmmod it when the testing is done.  Doing it that way just seems
> > more sane to me to begin with anyway.
> 
> No, tcrypt is only a relic for correctness testing.  Its main
> purpose these days is for speed testing.  Having to rmmod it
> is silly.
> 
> There's really no need to load tcrypt for correctness testing
> anymore.
> 

Not really sure I agree with the logic here.  I agree that its pretty clear that
its major value is for quickly testing all the algorithms in a system, but
universally failing the loading of the module simply to save a few milliseconds
seems like a poor choice.  In so doing you create an alias effect, as jarod
noted between a non-existent module and a module that failed to load.  The
aliasing can be resolved, if you want to parse dmesg, but if speed is the issue
at hand, that parsing is a significant impact.  If you allow the module to load
properly, then for the cost of an rmmod, you can tell simply from the exit code
of modprobe:
1) If the module was found 
2) If the tests passed

And if the rmmod is simply to expensive for whatever reason, then for the cost
of a few k of ram taken up by the module, you can choose not to unload it.

Of course, if tcrypt is really as much of a relic as you say, perhaps that is an
argument for removing the module entirely.  Perhaps the testmgr interface could
be exported to userspace and the tcrypt tests be packaged as a userspace suite.

Regards
Neil

> Cheers,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <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/