From: Blibbet <blibbet@gmail.com>
To: chipsec@lists.01.org
Subject: Debian packaging and D-I integration
Date: Wed, 22 Jul 2015 10:55:38 -0700 [thread overview]
Message-ID: <55AFD91A.6000205@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5494 bytes --]
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
next reply other threads:[~2015-07-22 17:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 17:55 Blibbet [this message]
2015-07-27 17:14 ` Debian packaging and D-I integration Loucaides, John
2015-07-27 17:42 ` Arrigo Triulzi
2015-07-27 17:47 ` Blibbet
2015-07-27 17:54 ` Loucaides, John
2015-07-27 18:46 ` Blibbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55AFD91A.6000205@gmail.com \
--to=blibbet@gmail.com \
--cc=chipsec@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).