5:51 a.m.
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?
Gordan
7:47 a.m.
On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic <gordan(a)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.
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. I'm
not sure if Ubuntu enables the OpenSSL combo or not, rebuilding the
package isn't very hard if it isn't...
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?
Gordan
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
--
Steev Klimaszewski <steev(a)genesi-usa.com>
Senior Software Engineer, Genesi USA, Inc.
7:53 a.m.
Steev Klimaszewski wrote:
On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic
<gordan(a)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.
> 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?
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.
Gordan
9:47 a.m.
On Tue, May 24, 2011 at 7:53 AM, Gordan Bobic <gordan(a)bobich.net> wrote:
Steev Klimaszewski wrote:
> On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic <gordan(a)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
--
Steev Klimaszewski <steev(a)genesi-usa.com>
Senior Software Engineer, Genesi USA, Inc.
6:23 p.m.
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
1:02 p.m.
On Tue, May 24, 2011 at 6:23 PM, Gordan Bobic <gordan(a)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(a)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.
--
Steev Klimaszewski <steev(a)genesi-usa.com>
Senior Software Engineer, Genesi USA, Inc.
9:46 a.m.
Hi Gordan,
On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic <gordan(a)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.
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(a)genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
10:29 a.m.
On 05/24/2011 03:46 PM, Matt Sealey wrote:
Hi Gordan,
On Tue, May 24, 2011 at 5:51 AM, Gordan Bobic<gordan(a)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
4718
days inactive
4719
days old
7 comments
3 participants
participants (3)
-
Gordan Bobic -
Matt Sealey -
Steev Klimaszewski