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

[Gordan Bobic]

Jason Burrell wrote:
> On May 25, 2011 6:06 AM, "Gordan Bobic" <gordan at bobich.net 
> <mailto:gordan at bobich.net>> wrote:
>  >
>  > Andrew Haley wrote:
>  >
>  > >> I'm not against NSS - really I'm not. But there are other 
> considerations
>  > >> to be taken into account.
>  > >>
>  > >> 1) Does NSS have any kind of support for hardware crypto offload? 
> If so,
>  > >> I haven't found any references to it (but maybe my google-foo is weak
>  > >> today).
>  > >
>  > > 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).
>  >
>  > This is particularly important for server applications. ARM is getting
>  > some traction in the server market. ZT make a really nice (if expensive)
>  > multi-ARM server. I have seriously discussed using ShevaPlugs/GuruPlugs
>  > specifically for large scale-out low-power SSL offload with clients.
>  > Crypto offload support is already important, and it's importance is only
>  > going to go up.
>  >
> 
> NSS supports PKCS#11 which most hardware crypto accelerators (including 
> things like smartcards and offloading coprocessors) use. As far as I 
> know, the only OpenSSL PKCS#11 library is external to it, from the 
> OpenSC people.

Hmm... Are the relevant kernel drivers and interfaces in place for 
PKCS#11 for any of the crypto offload engines discussed (Kirkwood, 
Tegra, Freescale)? Can somebody point me at the relevant interface docs?

>  > >> 3) Volume of supported commonly used software - if NSS has a clear
>  > >> advantage in terms of support base, then so be it, let's all put our
>  > >> weight behind it. But my perception is that this is not the case.
>  > >> Everything I touch upon on a daily basis seems to be linked against
>  > >> OpenSSL rather than NSS.
>  > >
>  > > Well, that's not true for everyone, and certainly not for users of
>  > > GPG.
>  >
>  > I thought it was mentioned on this thread recently that GPG brings it's
>  > own implementation anyway. Did I misunderstand?
>  >
>  > > But the real question is whether one group of Fedora developers is
>  > > determinedly going to push NSS and the other OpenSSL.  That is not a
>  > > route to happiness.
>  >
>  > It's not, but losing crypto offload and/or a performance drop-off and
>  > bloat due to shimming isn't a happy solution, either. If we can address
>  > those (the latter by sending patches to build against NSS upstream so
>  > shimming isn't required), then it'd be a great idea.
>  >
>  > But purely in terms of standardizing on a single crypto library - has
>  > anyone actually performed an exhaustive analysis on how much would need
>  > to be changed to go either way? The wiki page that has been referenced a
>  > few times seems distinctly non-exhaustive. Maybe my perception is
>  > non-representative here, but as I said, all the things I get my hands
>  > dirty on a regular basis are linked against OpenSSL rather than NSS. The
>  > pragmatist in me says that maybe that makes OpenSSL a better target to
>  > standardize on, but I would like to see an exhaustive analysis /
>  > empirical evidence showing otherwise.
>  >
> 
> "FIPS" OpenSSL isn't the same thing as "normal" OpenSSL. From OpenSSL's 
> own FIPS docs, "The FIPS Object Module is the special monolithic object 
> module built from the special source distribution identified in the 
> Security Policy. It is not the same as the OpenSSL product or any 
> specific official OpenSSL distribution release."
> 
> So requiring FIPS (which the US gov't and many large organizations do) 
> undermines the argument that OpenSSL is used more extensively.

So are you saying that the number of organizations that _don't_ use 
OpenSSH, OpenLDAP, mod_ssl, etc. is greater than those that do (limiting 
the field here to those that use some unix-like OS)? That would surprise 
me if it really is the case.

Gordan