While doing a bit of testing of some other crypto code, I've repeatedly
noticed a sha384 self-test failure. If you 'modprobe tcrypt', the
sha384 self-test fails, then immediately after it, sha384-generic
self-tests succeed. Something is awry w/sha384 initialization, as
can be more plainly seen by the following after a reboot:
# modprobe tcrypt mode=11 (run sha384 self-test)
dmesg
-----
alg: hash: Failed to load transform for sha384: -2
# modprobe tcrypt mode=12 (run sha512 self-test)
dmesg
-----
alg: self-tests for sha384-generic (sha384) passed
alg: self-tests for sha512-generic (sha512) passed
alg: self-tests for sha512 (sha512) passed
# modprobe tcrypt mode=11 (run sha384 self-test again)
dmesg
-----
alg: self-tests for sha384 (sha384) passed
Not sure offhand what's going awry, and don't have time to look deeper
right now, but will do so if nobody else gets around to it first...
--
Jarod Wilson
[email protected]
Jarod Wilson <[email protected]> wrote:
> While doing a bit of testing of some other crypto code, I've repeatedly
> noticed a sha384 self-test failure. If you 'modprobe tcrypt', the
> sha384 self-test fails, then immediately after it, sha384-generic
> self-tests succeed. Something is awry w/sha384 initialization, as
> can be more plainly seen by the following after a reboot:
>
> # modprobe tcrypt mode=11 (run sha384 self-test)
>
> dmesg
> -----
> alg: hash: Failed to load transform for sha384: -2
What kernel version and config? I can't reproduce this with
2.6.30-rc7. What does modinfo sha512_generic say?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tuesday 02 June 2009 01:10:27 Herbert Xu wrote:
> Jarod Wilson <[email protected]> wrote:
> > While doing a bit of testing of some other crypto code, I've repeatedly
> > noticed a sha384 self-test failure. If you 'modprobe tcrypt', the
> > sha384 self-test fails, then immediately after it, sha384-generic
> > self-tests succeed. Something is awry w/sha384 initialization, as
> > can be more plainly seen by the following after a reboot:
> >
> > # modprobe tcrypt mode=11 (run sha384 self-test)
> >
> > dmesg
> > -----
> > alg: hash: Failed to load transform for sha384: -2
>
> What kernel version
Straight up clone of cryptodev-2.6 -- i.e., not linus' tree + cryptodev
tacked on top. uname -r just says 2.6.29.
> and config?
Pretty much a dupe of the latest Fedora 11 kernel configs, run through
make oldconfig.
> I can't reproduce this with 2.6.30-rc7.
I'll rebase my cryptodev tree to 2.6.30-rcX and see if I can still
reproduce the problem.
> What does modinfo sha512_generic say?
# modinfo sha512_generic
filename: /lib/modules/2.6.29/kernel/crypto/sha512_generic.ko
alias: sha512
alias: sha384
description: SHA-512 and SHA-384 Secure Hash Algorithms
license: GPL
srcversion: 8709387FD8370A6569E17F3
depends:
vermagic: 2.6.29 SMP mod_unload
--
Jarod Wilson
[email protected]
On Tue, Jun 02, 2009 at 09:01:42AM -0400, Jarod Wilson wrote:
>
> > I can't reproduce this with 2.6.30-rc7.
>
> I'll rebase my cryptodev tree to 2.6.30-rcX and see if I can still
> reproduce the problem.
I just rebased cryptodev against 2.6.30-rc7 today so please let
me know whether you can still reproduce it with cryptodev.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tuesday 02 June 2009 09:20:38 Herbert Xu wrote:
> On Tue, Jun 02, 2009 at 09:01:42AM -0400, Jarod Wilson wrote:
> >
> > > I can't reproduce this with 2.6.30-rc7.
> >
> > I'll rebase my cryptodev tree to 2.6.30-rcX and see if I can still
> > reproduce the problem.
>
> I just rebased cryptodev against 2.6.30-rc7 today so please let
> me know whether you can still reproduce it with cryptodev.
Still happens after the rebase. Kernel config here, if it helps:
http://jwilson.fedorapeople.org/misc/cryptodev-2.6-config
--
Jarod Wilson
[email protected]
On Tue, Jun 02, 2009 at 03:41:34PM -0400, Jarod Wilson wrote:
> On Tuesday 02 June 2009 09:20:38 Herbert Xu wrote:
> > On Tue, Jun 02, 2009 at 09:01:42AM -0400, Jarod Wilson wrote:
> > >
> > > > I can't reproduce this with 2.6.30-rc7.
> > >
> > > I'll rebase my cryptodev tree to 2.6.30-rcX and see if I can still
> > > reproduce the problem.
> >
> > I just rebased cryptodev against 2.6.30-rc7 today so please let
> > me know whether you can still reproduce it with cryptodev.
>
> Still happens after the rebase. Kernel config here, if it helps:
>
> http://jwilson.fedorapeople.org/misc/cryptodev-2.6-config
Sorry, I still have no luck in reproducing this. I used the current
linux-2.6 which has the cryptodev tree merged, and the crypto bits from
your config file.
Any chance you can let me log onto your system to have a look?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tuesday 16 June 2009 07:22:50 Herbert Xu wrote:
> On Tue, Jun 02, 2009 at 03:41:34PM -0400, Jarod Wilson wrote:
> > On Tuesday 02 June 2009 09:20:38 Herbert Xu wrote:
> > > On Tue, Jun 02, 2009 at 09:01:42AM -0400, Jarod Wilson wrote:
> > > >
> > > > > I can't reproduce this with 2.6.30-rc7.
> > > >
> > > > I'll rebase my cryptodev tree to 2.6.30-rcX and see if I can still
> > > > reproduce the problem.
> > >
> > > I just rebased cryptodev against 2.6.30-rc7 today so please let
> > > me know whether you can still reproduce it with cryptodev.
> >
> > Still happens after the rebase. Kernel config here, if it helps:
> >
> > http://jwilson.fedorapeople.org/misc/cryptodev-2.6-config
>
> Sorry, I still have no luck in reproducing this. I used the current
> linux-2.6 which has the cryptodev tree merged, and the crypto bits from
> your config file.
>
> Any chance you can let me log onto your system to have a look?
Sure, I'll drop you the access info off-list in a sec.
--
Jarod Wilson
[email protected]