Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic
Jason Burrell wrote:
> On May 25, 2011 6:06 AM, "Gordan Bobic" <gordan(a)bobich.net
> <mailto:gordan@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
13 years
Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic
On 05/24/2011 07:27 PM, Alexander Boström wrote:
> mån 2011-05-23 klockan 15:15 +0100 skrev Gordan Bobic:
>
>> What I'm pondering now is something like a dkms package for the
>> cryptodev kernel module, but I seem to remember reading somewhere that
>> dkms is a non-Fedora RHEL thing. What do you guys think would be the
>> best way to approach it, especially since we don't have "standard"
>> kernels at the moment?
>
> It's probably a lot easier to just patch your kernel build (or ask
> whoever builds your kernel to do it). Then you won't need kernel build
> tools installed on your little arm device.
I really don't think that's a big deal. Cryptodev module takes seconds
to build, and even if you are building your own kernel, it means you can
just install the new kernel, and the new module with automatically be
built for it. So it still saves effort.
> Anyway, you'll also need support in various libraries and applications,
> which means that cryptodev.h must be available somewhere. The right
> place to put that is probably glibc-devel or kernel-headers, but that's
> not likely to happen until the support is in the mainline kernel.
I was thinking about including it in the dkms-cryptodev package. After
all, it is cryptodev module that brings it along.
> I suggest you try to help get cryptodev upstreamed into kernel.org or
> figure out why that hasn't happened. Once there's a solution in place
> upstream it's a lot easier to let the code trickle down naturally into
> all kernels and get support added to various related components.
My experience on the lkml has been that it's pretty difficult to not get
ignored. Perhaps somebody better established there might stand a better
chance.
Gordan
13 years
Fedora on PandaBoard
by orb
Hello,
Can someone point me to some basic instructions on getting fedora up and
running on OMAP4 PandaBoard? I would like to update omappedia.org with basic
instructions on getting this distro up. I am new to fedora so I would
appreciate a good place to start. I tried downloading F13 release based on
this thread --
http://lists.fedoraproject.org/pipermail/arm/2011-May/001271.html -- but I
am unable to download it. Is there another place I can get this? Can someone
post/send some binaries for me to try?
Any help on this matter would be greatly appreciated.
Thanks
Omar Barron
13 years
Should we and where could we document tasks and their progress?
by Niels de Vos
Hello all,
there is quite some activity on this list about different topics, this
is really encouraging! I'm just wondering how (I and possibly others)
can keep track of all this. Some of the topics are quite difficult to
keep up with and some pointers to the current status or options would
be very useful imho.
Personally I only have some hours distributed across the week to spend
on Fedora ARM. I'd like to use that time as effective as possible, and
that would include writing down what I did so that others can continue
where I left.
Some of the goals/topics that were recently discussed and which I
think that would benefit from some kind of tracking-page:
- Compile options, optimizations and multi-lib (at least for an
overview of considerations, comparisons and decisions)
- kernel package(s)
- bootloader integration
- updated buildroots for mock/koji
One way of tracking progress and creating some documentation would be
a page in the wiki, something like the Feature pages as has been done
for
- systemd: https://fedoraproject.org/wiki/Features/systemd
- GNOME 3: https://fedoraproject.org/wiki/Features/Gnome3
An other option would be to file a bug in bugzilla or a ticket
(https://fedorahosted.org/arm/) and work from there. For small things
this might work, for larger tasks that require more working together
it might be unsuitable. On other topics like the optimizations it
might be sufficient to a linaro forum where most of the discussions
take place. For a generic kernel package a git-repository (like
"fedpkg clone kernel") could possibly work out as well.
My main interest would be to have it listed in a place where I can
find it and read-up. I'm happy to start documenting some specific
topics, but would like some opinions from the rest of you.
Thanks,
Niels
13 years
fsck.ext3?
by Scott M. Jones
I'm trying the F13-beta3 rootfs on a Beagleboard-XM and I get this at
bootup:
fsck: cannot check /dev/mmcblk0p2: fsck.ext3 not found
fsck: cannot check /dev/mmcblk0p2: fsck.ext3 not found
I checked in /sbin and there is a fsck.cramfs but no fsck.ext3. My root
partition is ext3.
I am able to fsck by moving the SD card to an F14/Intel system, but is
there a package I can add to get the ext3 fsck on ARM?
Thanks,
Scott
13 years
