Hi Gordan, On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic <gordan@xxxxxxxxxx> 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. SAHARA is the one you would be looking at. SCC2 is for secure partitioning of the chip and peripherals to help out features like TrustZone, so it's not relevant (it can't be used by userspace to just "do" an AES block for you). 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. 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. 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. 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. 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? -- Matt Sealey <matt@xxxxxxxxxxxxxx> Product Development Analyst, Genesi USA, Inc. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
