Debian packaging and D-I integration

Debian packaging and D-I integration

[Blibbet]

[-- 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

Re: Debian packaging and D-I integration

[Loucaides, John]

[-- Attachment #1: Type: text/plain, Size: 8142 bytes --]

Lee,

I think it's a great idea to play with packaging, but as you mentioned, I do have some concerns about the driver. Your idea to play with this without submitting to a real repository seems good. Perhaps we can eventually come up with a deployable driver that would be ok to submit.

My suggestion would be for you to focus on adding chipsec to the install process rather than runtime. If you work this first, it buys us some time to work on bugs and think about what a deployable driver should look like. In the meantime, people could use chipsec during install and likely during boot without leaving the driver around during runtime. I think that would add a lot of value. (The issue with the driver is that it allows direct access to physical memory and hw resources. Malware in ring 3 could simply use the driver to bypass OS protections. However, if you're running malicious code during an OS install, you have bigger problems.)

In addition to getting this to work in the installer, you might look into installing it such that it runs before grub (i.e., before ExitBootServices).

Note that you'll probably only be able to get either of these working with secure boot off (because I would still not recommend signing this version). Let us know when you get something working, though. After some additional review and testing, we might come up with something to increase the comfort level with signing.

Another thing to think about before we submit anything to a distro... we should probably print some shorter and more friendly output. Perhaps something more like "Protection Found"/"Possible Vulnerability"/"Manual Assessment Needed"?

  BIOS Write Protection:                Possible Vulnerability
  SMI Suppression:                      Possible Vulnerability
  Compatibility SMRAM Lock:     Protection Found
  SMM Cache Poisoning:          Protection Found
  UEFI Variables:                       Manual Assessment Needed

How would others like to view/use this sort of information?

Thanks,
 - John

> -----Original Message-----
> From: chipsec [mailto:chipsec-bounces(a)lists.01.org] On Behalf Of
> Blibbet
> Sent: Wednesday, July 22, 2015 10:56 AM
> To: chipsec(a)lists.01.org
> Subject: [chipsec] Debian packaging and D-I integration
>
> 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
>
> _______________________________________________
> chipsec mailing list
> chipsec(a)lists.01.org
> https://lists.01.org/mailman/listinfo/chipsec

Re: Debian packaging and D-I integration

[Arrigo Triulzi]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Jul 27, 2015, at 19:14, Loucaides, John <john.loucaides@intel.com> wrote:
> My suggestion would be for you to focus on adding chipsec to the install process rather than runtime.

Some distributions offer the venerable “memcheck86” as part of their boot process both on their install media and once installed.

It would be a major achievement to convince some (if not all) to replace/add chipsec to this. Even if it does not run “by default” it would be a huge distribution achievement because it would then become trivially available for anyone trying to have someone run diagnostics remotely: telling someone “just go to Ubuntu and download the install USB stick and boot off it” is so much easier and less daunting than “let’s go about installing CHIPSEC”.

Then build on from there.

Arrigo

Re: Debian packaging and D-I integration

[Blibbet]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On 07/27/2015 10:14 AM, Loucaides, John wrote:
> I think it's a great idea to play with packaging, but as you
mentioned, I do have some
> concerns about the driver. Your idea to play with this without
submitting to a real
> repository seems good. [...]

Thanks for input. I'm a newbie at Debian packaging, so I expect you'll
have plenty of time to create more concise warning text. :-)

I'm getting start with private packaging. I'll file an Intent-To-Package
bug against Debian shortly.

Changes to D-I (Debian Installer) is a much larger effort, and would be
later. I have no idea if D-I team would have an interest in a patch with
this kind of feature yet.


Also, while on this thread, I received a few answers to my Debian
packaging questions:

> 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).

AFAIK the only way to load modules after the next boot following package
installation is to add it as part of the packages' installed init
scripts. Using init to manage any CHIPSEC binaries that need to have
things happen after they exit (i.e., unloading the kernel driver) might
be a good idea.

> 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.

The `debconf` program can handle cases like this. It's normally used for
install-time conditional package configuration (it's the thing that asks
questions during the d-i process: the keyboard configuration, static or
dynamic network addressing, etc. all are instances of debconf
configuring a specific package.)

Joey Hess' debconf tutorial is here:
http://www.fifi.org/doc/debconf-doc/tutorial.html

> 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.

Debian calls all the consumer-grade 64-bit arches `amd64` whether the
vendor is Intel or AMD; ia64 is the name for Itanium-based Intel 64-bit
chips. If CHIPSEC doesn't work on ia64 then it's a simple matter of not
providing a package for that arch, since Debian keeps separate archives
for each arch.

Re: Debian packaging and D-I integration

[Loucaides, John]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]


> I'm getting start with private packaging. I'll file an Intent-To-
> Package bug against Debian shortly.

Wouldn't it make sense to play with it first and *then* file one of these?
At this point, we're not sure when it'll be ready to submit... or exactly
what it will be when submitted.

> Changes to D-I (Debian Installer) is a much larger effort, and would be
> later. I have no idea if D-I team would have an interest in a patch
> with this kind of feature yet.

True, but it could be done before we'll have a deployable driver ready, and
it's likely to have a significant positive impact... kinda like that
memtest86 idea.

Thanks,
 - John


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6662 bytes --]

Re: Debian packaging and D-I integration

[Blibbet]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]



On 07/27/2015 10:54 AM, Loucaides, John wrote:
>
>> I'm getting start with private packaging. I'll file an Intent-To-
>> Package bug against Debian shortly.
>
> Wouldn't it make sense to play with it first and *then* file one of these?
> At this point, we're not sure when it'll be ready to submit... or exactly
> what it will be when submitted.

I'll check first, but I was told by a Debian expert that as soon as any
effort is started on packaging a new tool, an ITP bug should be filed,
to notify all concerned parties, to avoid duplication of effort. The bug
report is just notification of an intent-to-package, no changes to any
public repos, not exposing CHIPSEC code in any way. Hopefully, anyone
else also considering Debian packaging of CHIPSEC will also be reading
this list, and find this thread...

>> Changes to D-I (Debian Installer) is a much larger effort, and would be
>> later. I have no idea if D-I team would have an interest in a patch
>> with this kind of feature yet.
>
> True, but it could be done before we'll have a deployable driver
ready, and
> it's likely to have a significant positive impact... kinda like that
> memtest86 idea.

If I can get private packaging for CHIPSEC's current code, it'd IMO be
useful. If nobody has the package except people who read the warning and
have to build it themselves via private source tree (not public
packaging locations), then it's hardly different than people who install
CHIPSEC directly from Github, or via LUV source tree. Anyway, I'm not
kidding about being a newbie at Debian packaging: you'll likely have
ample time to update the driver code to be more deployable before I can
get initial packaging to work. :-(

BTW, there are both BIOS blobs and UEFI Application versions of memtest
apps. And I think there's a new UEFI-centric one on Github somewhere. A
UEFI-specific version of this tool could check UEFI's different kinds of
memory in ways I don't believe that a generic memtest app would be able
to do.  I think installers could offer some more firmware-specific HW/FW
diagnostics than they currently do. And there's also the MemTest module
of TianoCore, that could be offered to sysadmin via UEFI Shell of
UEFI-enabled GRUB/rEFInd. Installers can start to improve UEFI- and
BIOS-based diagnostics today with UEFI Shell, memtests, BITS, FWTS,
...and eventually CHIPSEC. Today, the "ALT Linux Rescue" distro includes
UEFI Shell. Multiple rescue-centric distros include memtest, most are
BIOS-based last time I checked.
http://wiki.phoenix.com/wiki/index.php/EFI_MEMORY_TYPE
https://aur.archlinux.org/packages/memtest86-efi/