← Back to team overview

ac100 team mailing list archive

Re: tegra-aes licence/bug


On 09/02/2011 05:49 PM, Henning Heinold wrote:
On Fri, Sep 02, 2011 at 05:32:05PM +0100, Gordan Bobic wrote:

I have here locally a patch which fixes completly the build of aes
and using the latest
stuff from the nvidia git tree. I have now pushed it to


Awesome, thanks Henning. I got the patchset that enables AES and it
didn't work against Marc's kernel tree (tegra-aes.[c|h] issues),
although it patched cleanly. I got those two files out of your tree
and rebuilt, and it seems to work now - module loads and the
availability is exposed in /proc/crypto! :D Going to do some testing
with cryptodev enabled openssl tonight. :)

Before I pushed I rebased it against the latest commits from Marvin24 and

There was a difference post-patch between the files in your tree and the ones I had. I'll

I already tried to get it working with the openssl engine, but it did not

I actually have with working. I can see the reference count on the module go up and get the expected output from "openssl speed -evp aes-128-cbc"

There seems to be a bug somewhere in the kernel module, though. At the end of the test run, I get:

*** glibc detected *** openssl: double free or corruption (!prev): 0x0067abd8 ***

I get this both with the new openssl 1.0.0d I just built and the older version that has been working correctly with AES offload on my SheevaPlug for a while. Also checked the new built openssl on the SheevaPlug and that works correctly without the mentioned double free error. I also did a package verify on glibc and that passes the checks.

So I'm guessing there is a but in the tegra-aes kernel module where it does something weird with the memory addresses.

Performance-wise, the AES speed is about 1/3 of what it is on a 1.2GHz Marvell Kirkwood, so as expected, it's not great, but it does seem to free up CPU time which I guess is the main point. Kirkwood's offloaded AES performance beats both Tegra's userspace and offloaded figures.

Tegra manages about 6400 8KB blocks in 3 seconds in software and about 2500 8KB blocks using the offload.

For Kirkwood figures, have a look here:

The method I used is the same (crytpodev kernel module).