[fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)

[omalleys at msu.edu]

Quoting Gordan Bobic <gordan at bobich.net>:

> Peter Robinson wrote:
>>>> Interesting question; not sure.
>>> I think it is an important one to answer, and sooner rather than later.
>>> This is particularly important to the ARM community since a lot of
>>> (most?) ARMs seem to have a crypto co-processor of some description
>>> (Freescales, Kirkwood and Tegra definitely seem to have this, I haven't
>>> checked others, but since these are the three classes of devices I own,
>>> that's 3 out of 3 - I don't think it's luck/coincidence).
>>
>> Remember this needs to be upstream in Fedora and other projects and
>> then Fedora ARM will get it by default. Work upstream, propose it as a
>> Fedora 16 feature and do the work.
>>
>> I don't think its particularly important to ARM. It certainly helps on
>> ARM due to low processing but its relevant on all platforms and most
>> platforms have some form of crypto offload built in to the core CPU
>> now days. Hell even the AMD geode processor used in the XO has it.
>
> Don't confuse crypto offload with crypto instructions. The new x86 stuff
> has crypto instructions that make AES churn faster, but that doesn't
> leave the CPU free to do other things while this is happening.
>
> My big concern is that the pursued solution will be one size fits x86,
> as often happens (also why the same packages need ARM patches in
> consecutive releases).

 From what I was reading in the kernel notes last night, the kernel  
crypto bits are optimized for multiple cores (multithreaded) and  
SEE3.1 enabled.

Given the kernel support for crypto, shouldn't this be in the kernel also?

>>>>> 2) More abstraction (a OpenSSL->NSS shim library), means more bloat,
>>>>> more context switching and less performance. Is that really the way
>>>>> forward? I mean _really_?
>>>> For bulk crypto operations an extra call via a shim probably doesn't
>>>> matter.  For some signature operations it might.
>>>>
>>>> It seems like a clean solution from the point of view of application
>>>> developers, though.
>>> The other thing that needs to be considered is added complexity and
>>> security. I would imagine that since there is an abstraction layer, it
>>> introduces additional scope for exploits (buffer overruns, stack
>>> smashing, etc.) Is this shim library going to also be FIPS certified? If
>>> not then the improved security aspect of NSS vs. OpenSSL comes a lot
>>> closer to pure marketing rhetoric (maybe that's where it's at at the
>>> moment anyway, I don't claim to be an expert on the subject).
>>
>> Read the details mentioned on the advantage of NSS over OpenSSL for
>> FIPS certification on the consolidation wiki.
>
> Are you talking about this sentence?
>
> "NSS, in contrast, allows all applications to inherit the NSS FIPS
> validation status by following some simple rules detailed in the NSS
> security policy document."
>
> I find it's a bit vague and opaque. I don't see how you could make the
> certification hereditary.

Think of something like DNSSEC, which hands your machine a  
certificate, then add something for your actual credentials, like  
another Cert on a smartcard, kerberos and/or OpenID, then add say VPN  
to the equation..

If you start looking at this scenario, then most traffic is going to  
be encrypted between all servers and all clients thus increasingly  
important that hardware support is enabled for crypto. And this is why  
crypto accelerators are pretty standard. It speeds up the client  
systems.

My question is, is everyone using the same crypto hardware accelerator  
or are they all different (which would be my assumption.) on the ARM  
Platform.

This whole scenario is a similar to the FPU, SIMD/MIMD, GPU  
Processing, Crypto issues.. I -wish- there was an easy moduler way to  
say, okay we have this function, lets use it.

The whole /dev/crypto if it is the right way to go.. reminds me of the  
/dev/rnd or /dev/urnd argument from way back when we used prng.

To me this means you need /dev/crypto (or something similar) for -all-  
devices regardless of hardware support or not, and all implementations  
need to use it.  The optimizations only have to be done once, (but can  
be overridden, as some algorithms are faster then others at specific  
tasks for the same type of encryption), and the scheduling is taken  
care of at the kernel level or at a library level but it has a unified  
interface so NSS, OpenSSL, etc. can all use it efficiently and it  
needs to be extensible to allow for future expansion.

Is that what we are aiming for?