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). >>>> 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. >>> 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. > > NSS supports HW. See above. All things need to be dealt with upstream. > Whether it be Fedora, kernel, NSS or other apps. Fair enough. I won't hold my breath and give up my OpenSSL quite yet, then. :) Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
