Hi,

I'm interested in CHIPSEC packages for Debian.

However, this is my FIRST attempt at doing Debian packaging, and CHIPSEC
a complex target, with Python, C, Intel x86 and x64 assembly, dynamic
kernel driver with security issues. I could use some help from others
that're more experienced with Debian packaging. If you want to help with
packaging, or know any answers to below qustions, please speak up.

For packaging, how about:

chipsec-uefi - UEFI binaries
chipsec-dkms - Linux kernel module src, compiled via dkms
chipsec-utils - Linux userland tools

Perhaps chipsec-uefi needs to be split up to one package per arch,
chipsec-uefi-x86, chipsec-uefi-x64, and chipsec-aarch64? Linaro is
investigating porting CHIPSEC to AArch64. If that happens, we'd need a
chipsec-uefi-aarch64 package. We could share the source packages, if
Linaro and Intel share same codebase, else may need separate source
packages for Intel and ARM flavors.

Right now, CHIPSEC driver gets loaded dynamically. Leaving the driver
loaded is a BIG security risk, see CHIPSEC's warning.txt file. AFAICT,
the big problem for CHIPSEC packaging is to keep the CHIPSEC Linux
helper driver unloaded most of the time, and only loade when CHIPSEC is
run, and unloaded afterwards. I don't understand how to address
packaging of drivers that do post-boot Linux module loading. From what I
gather, this ability would likely be disabled on more secure systems
(where CHIPSEC might want to be used).

I don't understand the Debian Python packaging specifics, and how this
impacts the package. There are separate guidelines for Python apps and
Python libraries, and CHIPSEC is both (it is multiple apps, as well as a
library). I'd like to find some example of an existing package with
Python code that loads/uses/unloads DKMS-based drivers.

I presume initially CHIPSEC packaging needs to not be put on a
mainstream Debian repository, to avoid driver security problems, and
only be kept on a private place, where only people who know the CHIPSEC
risks can install the package.

Most packaging happens in batch mode, non-interactively. But perhaps the
CHIPSEC driver package should display the contents of CHIPSEC's
warning.txt and let the use agree to this security risk, before
installing? If so, I need to find out how to do that in a Debian package.

Since CHIPSEC will only work on Intel x86/x64 systems, and not AMD-based
AMD64 systems, installation has to check CPU and only install on proper
systems. I'm unclear how to do this check in a Debian package.

LUV currently is the only Linux distro that ships with CHIPSEC. LUV is
Yocto-based, and as I understand it Yocto supports Debian packaging, but
I'm unclear if it can consume them or only produce them. Could LUV be
able to consume a Debian CHIPSEC package?

I'm also interested in getting CHIPSEC integrated to the installation
process. I really like the firmware diagnostic abilities of Linux UEFI
Validation (LUVos, and LUV-live), currently the only Linux distro that
ships with CHIPSEC (no packaging, Matt manually patches CHISPEC github
drops). I like how ALT Linux Rescue's ISO ships with an EFI-based boot
manager (rEFInd), and ships UEFI Shell on ISO's ESP, so user can boot
into UEFI Shell or continue running Linux installer. I'd like to see
some of those abilities in mainstream Linux installers. I think Debian
Installer (D-I) should offer the ability to have an ESP on it's ISO that
includes UEFi Shell, UEFI Python, and CHIPSEC. Then, D-I could let user
boot into UEFI to do pre-install diagnostics. It could also offer
additional Linux-based pre-install diagnostics (CHIPSEC, BITS, FWTS,
etc.) for additional pre-install diagnostics.

In addition to offering pre-OS and OS-present CHIPSEC as pre-install
tool, I think it'd also be useful to install CHIPSEC onto system, for
post-install-time use of CHIPSEC on the newly-installed Linux system.
Again, the issue of keeping the kernel driver unloaded and otherwise not
available to attackers is key.

One nice thing about integrating CHIPSEC with installer is that
install-time scopes use of CHIPSEC, and thus the CHIPSEC kernel driver
security is constrained to only when installer is run. (That's why I'm
complicating this packaging discussion with installer changes...)

I was talking to Paul Wise of Debian about install-time and
post-install-time use of CHIPSEC use, and he suggested some possible
workflows Debian could enable:

On a server:
apt-get install chipsec-efi-amd64
CHIPSEC auto-installed into UEFI boot menu
Reboot server
Select UEFI checks at boot menu
Checks complete successfully
Boot into OS

On a dev/sysadmin laptop:
apt-get install chipsec-efi-amd64-bin chipsec-tools
mkfs.vfat /dev/sdb1
mount /dev/sdb1 tmp
cp /usr/lib/chipsec/x86_64-efi/chipsec.img tmp
Eject USB stick
Boot USB on server
Select checks at boot menu
Checks complete successfully
Boot into OS

Download Debian hardware/firmware checks live CD/USB
Select UEFI checks at boot menu
Checks complete successfully
Boot into OS
Run OS-level checks

Download Debian installer
Boot in expert mode
Asks to check firmware security
Checks complete successfully
Continue installation

What other special CHISPEC packaging issues have I forgotten to consider?

Any other suggestions as to how to help improve Installer's Pre-OS/OS
use of CHIPSEC?

Thanks,
Lee Fisher
RSS: http://firmwaresecurity.com/feed