I think this was being described? http://fedoraproject.org/wiki/Features/CryptographyInKernel Adam On Wed, May 25, 2011 at 10:45, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > omalleys@xxxxxxx wrote: >> Quoting Gordan Bobic <gordan@xxxxxxxxxx>: >> >>> 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? > > It's an interesting approach, but I think it would be inefficient on > hardware without hardware crypto acceleration. I don't think there is > any inherent benefit in having all crypto done in kernelspace. Pushing > it through the kernel is only useful if the kernel can hand it off to > some underlying hardware and not worry about it until it gets back an > interrupt saying the data is crypted. If there's no underlying hardware, > context switching to the kernel will just make things slower. > > I like the uniformity of the idea (and how thin this would make the > userspace crypto libs), but all that skinniness of the userspace layer > would mean bloat in the kernel, which is worse. It would also make > things non-portable. So, sadly, I think the userspace will have to > continue to bring it's own implementation for where hardware isn't there > to help. > > Unless I'm misunderstanding what you were describing? > > Gordan > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/arm > _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
