Re: Debian packaging and D-I integration

--===============5761899052506026105==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Lee,

I think it's a great idea to play with packaging, but as you mentioned, I d=
o 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 pr=
ocess 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 boo=
t 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 i=
nstalling 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 sh=
ould probably print some shorter and more friendly output. Perhaps somethin=
g 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

--===============5761899052506026105==--