On Fri, Jul 24, 2015 at 12:54:23PM -0600, Kevin Fenzi wrote: > On Thu, 23 Jul 2015 10:19:26 -0400 > Chuck Anderson <cra@xxxxxxx> wrote: > > ...snip... > > > I would like to submit a new package that provides a Pre-Boot > > Authorization (PBA) image. The PBA is a "bootloader" of sorts that > > prompts the user for the passphrase to unlock a Self-Encrypting Drive > > (SED) using the TCG OPAL command set, and then either chainloads to > > the real OS or reboots to allow the BIOS to boot the real OS. The > > image gets installed to the OPAL SED as a sort of "shadow MBR/shadow > > disk image" using a special command "msed" (Manage Self-Encrypting > > Drive) that I also plan to submit a package for. > > So, the idea would be someone would 'dnf install' this package, run > msed and then reboot to have it take effect? Basically, yes. There would be a few msed runs, once to set the passphrase, once to load the PBA image to the drive, and once to enable the shadow MBR. I envision making this easier eventually, perhaps with a GUI for presenting a list of drives that support OPAL and providing the ability to encrypt them and load a PBA image for unlocking at boot. The nice thing about SEDs is that you can "encrypt" them without reinstalling--you are basically just setting the passphrase for the master key that is always being used inside the drive for the always-on encryption. > > In my case, I've developed a tiny embedded Linux-based PBA image [1] > > using Buildroot [2] and the MSED software [3]. The final image is a > > MBR-partitioned disk image with VFAT filesystem containing the > > specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the > > installed syslinux bootloader. > > > > Before you ask, I can't use even a stripped-down Fedora image for this > > purpose, because it must be TINY and it only exists to run a single > > command (linuxpba), then reboot. My image is 4MB and could be made > > even smaller. See the reasoning in [1] for why it must be so small. > > > > [1] https://github.com/cranderson/buildroot-linuxpba > > [2] http://buildroot.uclibc.org/ > > [3] http://www.r0m30.com/msed > > > > Now I know there are several challenges to using the Buildroot > > approach to building software for Fedora. Buildroot downloads > > software from the Internet, unpacks, patches, configures, and builds > > it. The build environment is built first, so gcc, uClibc, busybox, > > etc. and then the packages you want to include are built in that > > environment. > > > > What is the best approach I should use that is acceptable to Fedora? > > I'm not sure. :) > > > Would it be acceptable to bundle source packages, Buildroot itself, > > and my Buildroot configuration into one SRPM so everything is > > self-contained and can be built without requiring network > > connectivity? This means I would have to bundle the source code for > > gcc, the linux kernel, uClibc, busybox, etc. > > > > Or is there some way to pull in SRPM packages that already exist in > > Fedora, and use those as part of my build process so that I don't have > > to bundle all the source code? Additionally, I could made separate > > SRPM packages for Buildroot itself, any components needed (uClibc is > > already in the distro), the Buildroot build scripts for > > buildroot-linuxpba, and the actual package I need (msed). > > This sounds to me like something thats better suited to be composed and > shipped as some kind of image instead of being a package. Perhaps, but however it is delivered, it needs to be built somewhere by someone...and I don't think RelEng would be happy to have a build procedure that involved downloading sources from the Internet either... > I can see the appeal of a package however since it's so small. > > The build system will not let you download stuff from the net. > If we did builds would not be reproducable. Agreed. > You cannot use the existing gcc/busybox/etc to build the image? The msed "linuxpba" Linux userspace program is the one that prompts the user for the passphrase, does the unlocking, and reboots the system afterwards. It is written in C++ and links against ncurses. I haven't found a way to statically link the whole thing since it is written in C++, so it needs enough of a Linux userspace to be able to dynamically load libraries, access device nodes, etc. Everything else exists solely to boot up and run "linuxpba" in as tiny a way as possible. To keep things tiny, the kernel is built with most options turned off, and anything required is built-in (no modules)--including all SATA drivers. uClibc is used with a tweaked config file, again to keep things small. busybox is used as an "init" program and to launch "linuxpba"--most of the busybox options are turned off in the config. It might be possible to completely eliminate busybox as well, but I haven't figured that part out yet. The whole thing is built with a cross-compile toolchain. First the toolchain itself is built--the host gcc is used to build the cross gcc which then is used to build itself, uClibc, etc. The problem with trying to use pre-built versions of everything is the standard Fedora packages and userspace environment (glibc, libstdc++, etc.) are too big. > Alternately, how intensive is this image build? Perhaps you could > package the tools (as you are) and the end user can create their own > image? It is a bit much to expect the user to have to build gcc, uClibc, busybox, etc. on their own system. I haven't timed it, but even a ccache cached run takes 10 minutes or so, and that is with an SSD. Is there an existing Fedora "cross" toolchain for targeting a tiny i586/i686 Linux userspace with uClibc? Maybe I could use that to build linuxpba and the PBA image itself. I'd still need a custom kernel, because the standard kernel bzImage is already bigger than my entire PBA image, and that isn't counting the loadable modules. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
