On Tue, May 24, 2011 at 7:53 AM, Gordan Bobic gordan@bobich.net wrote:

Steev Klimaszewski wrote:

...

On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic gordan@bobich.net wrote:

...

Just looking at the specsheet of the Freescale i.MX515, and this jumped out at me:

Symmetric/Asymmetric Hashing and Random Accelerator (SAHARA) Lite is a cryptographic acceleration engine security co-processor

Implements:     * Block encryption algorithms (AES, DES, and 3DES)     * Hashing algorithms (MD5, SHA-1, SHA-224, and SHA-256)     * Stream cipher algorithm (ARC4)     * True hardware random number generator (TRNG)

Does anybody know at what kernel version the support for this was added (if it has already been added)?

It won't be in mainline as far as I am aware.

Ah, that's a shame.

From what I recall, it's more of a reference implementation, and

others (with the security manual) should be able to build their own drivers for it; that said, I've unfortunately had no time for testing it, though I really would like to. Maybe once 2.6.35 is out the door :)

...

...

And since I know the Genesi guys read this list, does the Kernel+OpenSSL combo that comes with Efika have this enabled as standard? (I lent my smartbook to somebody for a few days hence why I'm asking rather than just checking - I thought I'd get a head start on trying to get this working in the same way as it does on the Kirkwood (SheevaPlug).

I recall Matt enabling the option, I can't recall if it's in 2.6.31.14.20 or not, it's definitely enabled in the mx51_efikamx_defconfig if you checkout the latest from gitorious.

Have you got an URL handy for the relevant gitorius tree? Is there a patch against a kernel more recent than 2.6.31?

For the EfikaMX, at the moment, 2.6.31 is what you get; we're definitely hard at work on 2.6.35, which is what the latest BSPs have. Unfortunately running into a few issues with that kernel so at the moment, we can't release it (no, not even for beta testing, it's not even in the alpha testing stage yet :) )

...

I'm not sure if Ubuntu enables the OpenSSL combo or not, rebuilding the package isn't very hard if it isn't...

Yeah, just means I have to figure out how .deb builds work, I've never used it. I'm hoping it's vaguely similar to rpm.

It's actually not too hard when there is a package that already exists. You'd likely want to do something along the lines of

mkcd sandbox/openssl (just a little alias/script i have that makes a directory with the -p option and then cd's into it) sudo apt-get build-dep openssl apt-get source openssl (note that we aren't running this with sudo because we're planning on building it as a normal user)

This will download the sources to the latest version of openssl that is available for whichever version you're on (Maverick is what it should be) It will extract them, and put them into the directory something like openssl-0.whatever

Just go into that directory, and look inside the debian directory, typically you'd just want to edit the rules file to add whatever configure flag you want, depending on how they build it.

You'll also want to update the changelog, either manually, or via the command "dch" (part of the devscripts package which will pull in a LOT of dependencies) Update the version number to whatever you want, and then run the command (from inside the openssl-0.blah not from the debian directory)

"dpkg-buildpackage -uc -us"; if you don't plan on distributing it, you can add -b which will only build the binary package, otherwise it will re-generate the sources as well with your changes. -uc means unsigned changelog, -us means unsigned sources.

Wait a bit for it to finish compiling, and then in .. you should see the new .deb files. install the one(s) you need, and you should be good to test.

(this was a quick non-official tutorial, and I may have glossed over a few steps, but it should definitely get you on your way :) )

Gordan

-- Steev

On Tue, May 24, 2011 at 6:23 PM, Gordan Bobic gordan@bobich.net wrote:

On 05/24/2011 03:47 PM, Steev Klimaszewski wrote:

...

mkcd sandbox/openssl (just a little alias/script i have that makes a directory with the -p option and then cd's into it) sudo apt-get build-dep openssl apt-get source openssl (note that we aren't running this with sudo because we're planning on building it as a normal user)

This will download the sources to the latest version of openssl that is available for whichever version you're on (Maverick is what it should be) It will extract them, and put them into the directory something like openssl-0.whatever

Ah - this could turn out to be more problematic to do distro-wide than I'd hoped. Ubuntu 11.04 seems to ship with OpenSSL 0.9.8o. I'm not sure if the cryptodev support is available in that version. A little disappointing, really, since 11.04 was released last month and OpenSSL is way out of date. F13 and RHEL6 both ship with OpenSSL 1.0.0.

cryptodev driver also fails to complete because the kernel headers are incomplete (missing mach/memory.h - mach should be a symlink to arch/arm/mach-mx5/include/mach, but mach-mx5 is empty except for the build scripts.

I'd mutter something about teletubby distros, but given this is Fedora list, I'd probably be preaching to the choir. </rant> ;)

Gordan _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

http://packages.ubuntu.com/oneiric/openssl

They use openssl 1.0.0 in oneiric, realistically, it should work fine on Maverick, though it may require other dependencies to be upgraded, what I like to do on my personal machines to test, is grab the package, update the changelog and change the oneiric to maverick (very bad of me but meh, I'm just testing it out), and build it.

As for the mach, you can checkout the kernel sources, and then symlink it that way. This has been a known bug for ages, and I *think* the only thing we could possibly do to move it around is to generate our own libc6-dev package.

On 05/24/2011 03:46 PM, Matt Sealey wrote:

Hi Gordan,

On Tue, May 24, 2011 at 5:51 AM, Gordan Bobicgordan@bobich.net wrote:

...

Just looking at the specsheet of the Freescale i.MX515, and this jumped out at me:

Symmetric/Asymmetric Hashing and Random Accelerator (SAHARA) Lite is a cryptographic acceleration engine security co-processor

Implements: * Block encryption algorithms (AES, DES, and 3DES) * Hashing algorithms (MD5, SHA-1, SHA-224, and SHA-256) * Stream cipher algorithm (ARC4) * True hardware random number generator (TRNG)

Does anybody know at what kernel version the support for this was added (if it has already been added)?

And since I know the Genesi guys read this list, does the Kernel+OpenSSL combo that comes with Efika have this enabled as standard? (I lent my smartbook to somebody for a few days hence why I'm asking rather than just checking - I thought I'd get a head start on trying to get this working in the same way as it does on the Kirkwood (SheevaPlug).

I also notice there is this in the i.MX515: Security Controller (SCC) type 2 * AES engine * Secure/Non-Secure RAM * Support for multiple keys and TZ/non-TZ separation

Does this mean there are two independent AES crypto co-processors in there? What about kernel support?

There is kernel support for Freescale's generic test-based "SHW" interface which is mostly a userspace interface to the kernel, but no support for anything like cryptodev (since there is no in-kernel cryptoapi support for Sahara).

We were planning on working on it in the near future. It's important to us but not top of the list. It would be super useful for ecryptfs swap and home directories. Freescale said they're going to support cryptoapi in the kernel with the MX6 and so on and so forth, for various reasons, and their crypto teams do have working cryptoapi implementations for Talitos (PowerQUICC/QorIQ) already so it is not as if they are ignorant of the need for it. It just never got done for Sahara and we have decided to pick up the slack when we have time.

For some reason I find it really shocking that some manufacturers go to the efford of designing the hardware and then don't make sure that the suitable software support is available as soon as the hardware starts sampling...

Problem: cryptodev is an inefficient API (lots of memory copies) as would be any crypto exposure from userspace to kernelspace, so the actual performance even of the Kirkwood engine leaves a lot to be desired and is far from the hardware performance. This is why Intel and Via implemented it with CPU instructions - no kernel marshalling required, you just do it.

Indeed, I am aware of that, but that just makes AES calculations faster, it doesn't actually offload them. The CPU cannot do other things while the crypto is crunching in the background. As the figures in the article I posted show, the big win isn't so much that it runs faster - it does, but it's a factor or so, not orders of magnitude (on 8KB blocks it was hitting about 60% of it's rated 300Mb/s - and I'd expect that to go up with bigger blocks). The big win is that it leaves the CPU idle and free to do get on with other things. It's more like "free crypto" rather than "faster crypto". :)

BTW as an alternative to cryptodev why doesn't Fedora make the leap like it did with systemd and go for the new netlink crypto interface? As long as the kernel has a cryptoapi driver and the encryption software in userspace utilizes the new netlink interface, there's no need for merging cryptodev or DKMS module compilation messes.

I really don't think dkms-ing cryptodev is that messy or difficult, but I'll reserve the right to be wrong until I have it working. :)

It's already mainline in 2.6.39 AFAIR. Someone will need to kick OpenSSL and any other encryption libraries into shape to get it to work, but I suspect someone has already done that somewhere.. it would also be a depdendency-less way to get it into the coreutils binaries.

I like that idea, but considering how long it has taken to get cryptodev support into OpenSSL and working on Linux, I don't see it happening overnight - especially since even the bleeding edge Fedora doesn't even include support for cryptodev as standard. It may be a step too far to expect soon. Worthy of pushing for, for sure - but it'll take a lot more work, and we can have cryptodev _now_. Even though it isn't as efficient as it could be, it's still better than software-only.

It would still suffer from the same memory copy issue as cryptodev though. The "0% cpu usage" you see is probably not taking into account the time wasted doing the userspace to kernel part.

As I said elsewhere, with 8KB blocks, the CPU idle time goes to about 70% (it's firmly at 0% when using tiny blocks, and the performance figures reflect that - it's not faster with small data blocks), and yes, that is nowhere near the near-0 CPU time OpenSSL reports, but it's still a non-trivial improvement that's worth having for any realistic use-case. For example:

1) On ssh running top in a 132x40 xterm, that is at least 5280 bytes per refresh. top -n1 seems to be 6416 bytes in the dump, presumably due to escape characters. This compresses down to 1045 bytes, which is certainly past the point where we start to win on crypto offload.

2) Currently the average size of an "object" on the internet is about 16KB or so, IIRC, and at these size we are way above the curve when it comes to things like HTTPS SSL offload.

Finally - if the copy overhead is still there, then what is the advantage? Is there, perhaps a better way of doing it, using DMA, and just passing a pair of pointers to the coprocessor?

What would make it clear is if you could run some kind of web benchmark over SSL where data was being streamed in - if it's faster (objectively running Javascript or an HTML5 demo or something that deals with heavy network load which would need to be encrypted and decrypted) then you are onto a winner, otherwise it may be that it is just hiding the work. How exactly would we determine whether the security engine is really making a difference to performance?

Well, I'd say the CPU idle time going from 0% to 70% is a reasonable start, but yes, I completely agree, something like apachebench over SSL is probably the way forward. I'll look into it when I have a chance.

Gordan