Debian signed Shim

Secure Boot chain-loading bootloader (Microsoft-signed binary)

This package provides a minimalist boot loader which allows verifying signatures of other UEFI binaries against either the Secure Boot DB/DBX or against a built-in signature database. Its purpose is to allow a small, infrequently-changing binary to be signed by the UEFI CA, while allowing an OS distributor to revision their main bootloader independently of the CA. This package contains the version of the bootloader binary signed by the Microsoft UEFI CA.




TrouSerS getting kicked out of Debian?

Thomas Habets points out on the trousers-users list that TrouSerS, the open source TPM stack, is getting kicked out of Debian, due to it’s lack of OpenSSL 1.1 support. I hope someone at TrouSerS is working on this. Tomas has a similar tool, Simple-TPM-PK11, and has made similar changes in his tool, that TrouSerS will need to do, and describes this in his post to trousers-users.







DebConf, Debian’s annual conference is happening in Cape Town, South Africa. Even if you aren’t in Cape Town this week, the DebConf event team is very good at providing postconference video archives, look for them to be available shortly.


Amongst the many interesting presentations, here’s a few firmware-related presentations to look forward to:

Secure Boot BOF
Ben Hutchings
Secure Boot is a UEFI feature that prevents unsigned boot code from being loaded. Assuming the bootloader checks the signature on the kernel, and the kernel checks the signature on code it itself loads, this chain of trust can be extended quite far into the running system. Unfortunately, the only signing key that is trusted by most implementations is held by Microsoft.
There are 2 major reasons for supporting Secure Boot in Debian:
 * some computers now ship with Secure Boot enabled by default, making it harder to install Debian;
 * while not perfect, it is a technology that can be used to make Debian user safer.
The plan the Ben (bwh) has been hatching is as follows:
 * a minimalistic shim bootloader is signed by Microsoft;
 * the shim load a bootloader that was properly signed by Debian (in the long run, ftpmaster@; right now, it’s bwh’s signing key);
 * the bootloader loads a kernel signed by Debian;
 * the kernel only accepts to load code signed by Debian (securelevel = 1).
The signing process itself uses signature packages, so as not to keep signing keys on the buildds or break reproducibility.
 * no dependency on Microsoft, once the shim is signed (and it should need fixes very seldom);
 * robust process that can take advantage of reproducible builds;
 * gives reasonable guarantees that the running kernel is a legitimate one;
 * trusting only Debian (as opposed to anything Microsoft signs) can easily be achieved by shipping a Debian-signed shim and having the user put the Debian key as the only trusted one.
 * doesn’t protect the userspace (yet!);
 * still vulnerable to somebody with a kernel exploit (but this doesn’t grant persistence) or who can get a bootloader signed by Microsoft.
Help us, fellow Debian hackers! You are our only hope.

Secure Boot for Debian Linux
Ben Hutchings
Three years after a “Plan of action” for Secure Boot support, we’ve had another release without it and there are still many changes required. What is left to do and how will we finish it in time for “stretch”?

Using LAVA for Debian
Neil Williams
How to use LAVA to provide test support on real hardware which can be remote or local to the user.
 * lava.debian.net
 * publish local tests from your desk to support testing packages like u-boot.
 * install lava-dispatcher on a machine on your LAN and publish local tests for everyone to view and analyse
 * run CI on the Linux kernel packages on hardware – ramdisk, NFS and SATA media
 * test DI on real hardware (typically ARM).
 * publish local tests of VM images, including live images, and potentially run tests on VM images where appropriate hardware is available.
 * run server-client tests on relevant hardware which cannot be easily performed in sbuild or single VM instances.
 * support for VLAN testing is available although unlikely to be via lava.debian.net itself.
 * support for Debian SSO for account creation.
 * XMLRPC and REST API interfaces.

Debugging the IoT
Bdale Garbee Bernelle Verster Andy Simpkins
Panel discussion, aimed at the general public and more technical participants alike. The panel will discuss the open hardware movement, and how it fits in with Smart Homes. It will highlight and discuss the futurology, trends, and challenges. Challenges include security, the role of big vendors, the requirement for a more powerful platform, competing interests and the role of industrial providers. The panel will be hosted by Bernelle Verster, and panelists include Andy Simpkins and others. (Please get in touch if you want to be on the panel too).

Debian on ARM devices
Martin Michlmayr
This talk will cover Debian on ARM devices, including NAS devices, development boards and other devices. The talk will briefly explain how the installer works on ARM from the point of view of a user. It will then cover in detail how Debian on ARM is different to Debian on x86 devices and what infrastructure we created in Debian to support a wide range of ARM devices, such as flash-kernel. Some supported platforms and devices will be covered as well.


Imagination donates MIPS hardware to Debian

It looks like a few companies, including Imagination Technologies, the current company behind MIPS processors, has donated some hardware to the Debian project!

 […] Imagination Technologies recently donated several high-performance SDNA-7130 appliances to the Debian Project for the development and maintenance of the MIPS ports. The SDNA-7130 (Software Defined Network Appliance) platforms are developed by Rhino Labs, a leading provider of high-performance data security, networking, and data infrastructure solutions. With these new devices, the Debian project will have access to a wide range of 32- and 64-bit MIPS-based platforms. […] The Debian project would like to thank Imagination, Rhino Labs and aql for this coordinated donation. […]


PS: I mostly pay attention to Intel and ARM hardware, it’s been a while since I’ve worked on a MIPS box. Just catching up to MIPS after years, there’s a lot of firmware exploit research out there:


Debian drops Intel 486/586 support for i386 target

Ben Hutchings announced a policy change at Debian, i386 must now be 686-class processors:

Debian i386 architecture now requires a 686-class processor:

Last year it was decided to increase the minimum CPU features for the i386 architecture to 686-class in the stretch release cycle.  This means dropping support for 586-class and hybrid 586/686processors.(Support for 486-class processors was dropped, somewhat accidentally, in squeeze.) This was implemented in the Linux kernel packages starting with Linux 4.3, which was uploaded to unstable in December last year. In case you missed that change, gcc for i386 has recently been changed to target 686-class processors and is generating code that will crash on other processors.  Any such systems still running testing or unstable will need to be switched to run stable (jessie). The older processors will continue to be supported in jessie until at least 2018, and until 2020 if i386 is included in jessie LTS.

[1] The following processors, supported in jessie, are now unspported:

* AMD K5, K6, K6-2 (aka K6 3D), K6-3
* DM&P/SiS Vortex86, Vortex86SX
* Cyrix III, MediaGX, MediaGXm
* IDT Winchip C6, Winchip 2
* Intel Pentium, Pentium with MMX
* Rise mP6
* VIA C3 ‘Samuel 2’, C3 ‘Ezra’

True, this is not firmware-centric, but Debian is pretty upstream when it comes to embedded Linux systems…

For more info, see the full post on the debian-devel-announce list:



Debian plans for UEFI Secure Boot

Steve McIntyre of the Debian Project posted a message to the Debian-EFI list, with plans for getting Debian to support UEFI Secure Boot. A summary of the main steps:

1. Generate a key and an EV code-signing cert, submit to Microsoft
2. dak changes to support upload and signing of EFI executables
3. Prepare and upload a package of the ‘shim’ EFI boot loader
4. Updates for other core packages to add signed versions
 * grub2
 * linux
 * fwupdate
 * ???
5. Minor tweaks to other places to make use of the signed packages
 * d-i
 * debian-cd
 * debian-live
 * ???

Full status message and more information: