arm May 2011

arm@lists.fedoraproject.org

35 participants
26 discussions

Start a nNew thread

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 25 May '11

25 May '11

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

1 0

Fwd: [Fedora-trans-ru] Выпуск Fedora 15
by Misha Shnurapet 24 May '11

24 May '11

1 0

Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 24 May '11

24 May '11

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

2 4

Fedora on PandaBoard
by orb 19 May '11

19 May '11

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

2 1

F13 Beta 3 - wrong yum repos?
by Quentin Armitage 18 May '11

18 May '11

F13 Beta 3, at least at http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/… has fedora-release-13-1.2.beta2.noarch.rpm but presumably this should be beta3. Looking at the /etc/yum.repos.d/*repo files in that package, they not surprisingly point to http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-03-23/f13-arm/arm/… which are the Beta 2 packages. Presumably, if Beta 3 is installed, then any additional packages installed via yum will pull in the Beta 2 packages. The only packages that I have installed on Beta2 that are upgraded in Beta3 are thte gcc suite and perl-version. I intend to edit the /etc/yum.repos.d/* files to point to the new location and install them; presumably that's an easy way to get to Beta3. Hope this make sense, Quentin Armtitage.

1 1

Should we and where could we document tasks and their progress?
by Niels de Vos 17 May '11

17 May '11

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

1 0

fsck.ext3?
by Scott M. Jones 15 May '11

15 May '11

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm May 2011