Rescatux adds new UEFI rescue options

Adrian announced Rescatux 0.41b, with new UEFI rescue options:
(*) Change UEFI Boot order
(*) Create UEFI Boot Entry
(*) Fake Microsoft Windows UEFI.
(*) Hide Microsoft Windows UEFI
(*) Reinstall Microsoft Windows UEFI boot entries

Adrian has a thread on the debian-efi list, asking for feedback on these features. Excerpt of announcement below, see the full announcement on the debian-efi list.

Rescatux 0.41b1 released with UEFI rescue options

* Rescatux introduction
Rescatux is a GNU/Linux rescue cd (and eventually also Windows) but it is not like other rescue disks. Rescatux comes with Rescapp. Rescapp is a nice wizard that will guide you through your rescue tasks.[…]
* Rescatux 0.41b1 released
Last week I released Rescatux 0.41b1 with a bunch of new UEFI rescue options. I just wanted to share with you some technical details about those options so that I can get some feedback from you.[…]

ALT Linux Rescue also has the option to boot either into their Linux or into their provided UEFI Shell. I wish more Linux distirbutions provided features like this.

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

Kali for Intel Edison

hackgnar has a new blog post out, showing how to build Kali for Edison targets:

Building Kali Linux for Intel Edison: This documentation goes though the process of manually building a base Kali Linux image for the Intel Edison board. These steps were derived from frankensteining the edison build scripts for Debian Jessie and some of the Kali Linux ARM build scripts. All of the content from this post can be found in my github repo for this project here, along with pre compiled images (coming soon!) and ansible scripts for automated building. Note, all of these steps were tested in Ubuntu Linux 14.04 x64 LTS. As of this writing, this OS/Version has the most support for doing Edison source builds. I have done these steps in other operating systems, but the process is not as clean due to bugs, script tweaks, etc. […]

Kali 2016.1 UEFI user experience notes

Debian Derivative-based Kali just released a new release, with UEFI support, based on upstream Debian. J.A. Watson wrote an article for ZDNet about trying to install the latest release, focusing on UEFI issues. I’ve included a few UEFI-centric excerpts below. Additionally it sounds like the Kali Mini version is based on Debian netinstall, “but it doesn’t boot on a UEFI system”.

[…]  To top it all off, the new distribution is UEFI compatible, and installed without any problem on the systems I have tried so far. This is really the best news of all for me, because I have spent huge amounts of time fighting to get the previous Kali distributions properly loaded and configured on UEFI systems (NOT in Legacy boot mode). […]  It looks to me like what they have finally done is what I thought they should have been doing all along – they simply use the Debian installer, which has been able to deal with UEFI for ages. […] The new ISO images can be obtained from the Kali Downloads page, and these are also a pretty impressive creation. They can be booted in (normal) Live mode, in (forensic) Live mode, or they can be directly installed. As far as I can tell there is no way to install from a Live boot, and I consider that to be a good thing because the previous Live installers didn’t work worth beans on UEFI firmware systems. […] The bottom line is, the new Kali release is here, it’s beautiful, it works, even on UEFI firmware. […]

Full article:

RIP Ian Murdock, creator of Debian


Linux Foundation: combining Yocto with Debian

The CE Workgroup of the Linux Foundation occasionally does bids for research or work for related projects. One of the projects they’re interested in is supporting meta-Debian, a Yocto project that integrates with Debian. Earlier this week Tim Bird, Architecture Group Chair, CE Workgroup of the Linux Foundation, announced their proposals, exerpted here to focus on the Debian/Yocto project:

The CE Workgroup of the Linux Foundation occasionally solicits contractors for projects they are considering.  The following projects is currently under consideration for funding this year, and the CE Workgroup would be interested in hearing from you if you would like to work on them (and be paid for it!) For a while now, CEWG has been studying the feasibility of combining the Yocto Project with Debian, to create a system for using the Debian distribution for embedded projects.  The first proposal above, intends to solicit (paid) contributions to extending CEWGs project to more hardware and to include more libraries in the target distribution. If you are interested and are willing to get paid to work on this (producing or enhancing open source software to benefit the entire embedded industry), then please contact Tim Bird.

For the full announcement, see posting by Tim Bird. I’ve excerpting Tim’s announcement to only mention the meta-Debian project: he also mentioned two other projects, see the full announcement for details on those.

IMO, it would be nice to have Intel contributing to Debian in this way, providing Yocto-based vendors with more opportunities to use Debian, and helping Debian with embedded BSP (and hopefully some QA).

A bit of background on meta-debian, and some related projects:

new resource: Broken UEFI Implementations wiki

Watch this site to grow over time (and contribute to it, if you can help):

Apple, Lenovo, GIGABYTE: note that there’s some stuff about your products in the initial database.

As mentioned earlier:

Steve McIntyre of the Debian project is working with other open source OS developers to maintain a list of broken UEFI implementations, to help OS vendors:

I’ve been talking to a number of other UEFI developers lately, and we’ve agreed to start a cross-distro resource to help here – a list of known-broken UEFI implementations so that we can share our experiences. The place for this in in the OSDev wiki at We’re going to be adding new information here as we find it. If you’ve got a particular UEFI horror story on your own broken system, then please either add details there or let me know and I’ll try to do it for you.

See Steve’s blog post for more information:


Intel update on Debian and UEFI

Yesterday Brian Richardson of Intel UEFI posted a new blog entry on 32-bit UEFI and Linux support, with specific information about Debian.  It was NICE to see the Debian swirl as the icon on an blog post! 🙂 I am sometimes concerned that UEFI Forum and Intel only think about UEFI Forum-member Linux OSVs (Canonical, RedHat, SuSE) when it comes to UEFI and Linux. It’s NICE to see Intel working with non-UEFI Forum members on UEFI issues, especially Debian!

Blog excerpt:

“Thanks to Steve McIntyre from the Debian team for pointing out my error. Steve’s also helping organize a repository for information on UEFI implementations that don’t play nice with Linux. I think this is a great idea, so check it out if you have any relevant info. I’ll share my tips for testing UEFI & Linux in an upcoming post, in case you want to contribute to their project.”

Brian@Intel’s full blog post:

Steve@Debian’s blog post:

This repo of Linux UEFI information sounds GREAT!. Amongst the things it tracks, I hope it tracks the various Secure Boot strengths that Linux distributions have:

Debian calls for UEFI packaging help

Steve McIntyre of Debian posted a blog the other day, they’re doing more to help with UEFI in Debian. If you can help, this is the most upstream distribution…

I’m not good at packaging, but am currently learning. If you want to help with Debian packaging for CHIPSEC, please let me know, or join the thread on the CHIPSEC mailing list.

Linux distros (and FreeBSD): join the UEFI Forum

Hey Linux/FreeBSD distros: it’s great that you’ve got UEFI support including Secure Boot certs. But that’s not enough, you need to join the UEFI Forum, and help evolve UEFI to be more Linux-friendly.

Right now, the last time I checked, the only Linux distros that had joined were: Canonical (Ubuntu), Red Hat, and SuSE. As well as Linaro. Excluding SuSE and Redhat’s commercial products, that means that Ubuntu, Fedora, and OpenSUSE are the community Linux distros that may have the best UEFI support.

UEFI Forum members have access to:
* member-only communications (web forums)
* member-only invites to meetings/events (including the 1-3 plugfests they do each year).
* member-only access to software and specs the public doesn’t have.
* access to file bugs/change requests, which the public cannot do.

I think you get access to their non-public trunk, a subset of which is exported to the public as TianoCore, but I’m not sure. (Hypocritically, I’m not a member yet, still working on it, blocking on some new company infrastructure.)

If you join, you can help evolve and improve UEFI, and have early access to UEFI resources so your distros can be ready for any changes. You can attend the plugfests and do interop testing with other UEFI products/projects, to find problems before your users have to see them.

If you don’t join, you’ll be constantly reacting to UEFI Forum releases, have less resources than UEFI Member distros have, and if there’s a problem all you can do is whine and blame Intel and/or Microsoft, when you should look into the mirror instead.

The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.

In addition to Linux distros, FreeBSD also supports UEFI, and is not a UEFI Forum member. iX Systems and FreeBSD Foundation: this also applies to you.

You also need to register your distro with the UEFI Forum’s ESP Subdirectory Registry, so you can have some UEFI binaries (boot loader, etc.) in a well-known location. Ex, if Debian’s cbootstrap gets ported to a UEFI Application, then \EFI\Debian\cbootstrap.efi would be an example of where the file would be stored. Right now, Debian is registered, but not a member of the UEFI Forum!?

Intel, ARM, Linaro, Red Hat, SuSE, and Canonical have been doing a great job improving UEFI so it works better with non-Apple, non-Microsoft operating systems. IMO, more distros need to get involved and help.

More Information:

While I’m on my soapbox, Linux distros should consider some UEFI-centric rescue options in their boot CDs. ALT Linux Rescue ISOs include rEFInd boot manager, and let you optionally jump into UEFI Shell. You could use UEFI-aware GRUB for this, instead of rEFInd. Additionally, it would be nice to also give access to running: FWTS (FirmWare Test Suite), Intel CHIPSEC to test the hardware/firmware for security. It would also be nice to include the UEFI port of CPython 2.7x, along with the UEFI Shell, for more powerful diagnostic abilities. Distro installers should also consider installing UEFI Shell and UEFI Python and CHIPSEC onto system’s ESP, in an advanced mode, not just let them access via install ISO. Of course, there are security issues by enabling extra Pre-OS tools, user would need to opt-into all of this. Intel’s LUV-live, which Linaro is porting to AArch64, contains BITS (BIOS Interface Test Suite), FWTS, CHIPSEC all in one convenient location. I hope other Linux distros emulate some of LUV-live’s diagnostic and rescue abilities.

Secure Boot strength varies by Linux implementation

[UPDATE, with input from readers, see EOM. Thanks!]

UEFI Secure Boot is a build-time feature of UEFI that helps secure the boot process from some boot-time attacks, optionally using TPM hardware if available. Secure Boot became widespread on Windows hardware during Windows 8 timeframe. Windows aside, other operating systems have to support UEFI Secure Boot. Linux supports UEFI and UEFI Secure Boot (as does FreeBSD). Different Linux distributions have different Linux kernels, with different versions, different patchsets, and different build-time directives enabled. So, Fedora’s Linux kernel is different than SuSE’s Linux kernel, etc.

I saw a recent comment from a UEFI security researcher who had been building a Linux liveboot CD and running CHIPSEC — which includes a native Linux kernel driver, and running it on UEFI systems with Secure Boot enabled.

“Ubuntu appears to have shim and do secure boot but not enforce kernel module signing.”

This Ubuntu behaviour was a change in behaviour from the Fedora-based systems the researcher was used to using. I was curious about the difference in distros w/r/t enforcing kernel module signing. So I asked on the FirmWare TestSuite (FWTS) list if there was a test for this. Roderick W. Smith of Canonical — and author of rEFInd boot manager and the definitive Linux boot loader/manager reference on — replied clarifying the situation:

“Yes, that’s correct. Ubuntu’s kernel doesn’t attempt to enforce Secure Boot policy beyond the main kernel file; once the kernel’s loaded, it’s possible to load an unsigned kernel module. Fedora, as you inferred, does require signing of kernel modules. Fedora’s approach is arguably more secure, since an attacker can’t load a malicious kernel module once the system has booted, but leads to problems with third-party kernel modules, like the in-kernel portions of nVidia and ATI/AMD video drivers. FWIW, the decision to do it this way was made before I joined Canonical, so I’m not sure who made the decision.”

Ivan of Canonical replied with more information:

“On Linux, two stage booting has implemented for secureboot. First stage is firmware boot to shim and then shim will take care to check signature and boot with grub and kernel. Booting with/without kernel signed is under shim and grub implementation, Ubuntu provides the singed kernel in official releases, and would like to keep the flexibility for user to build their kernel, so Ubuntu doesn’t block booting when user uses unsigned kernel.”

The security researcher who reported this speculated that Canonical’s policy may be due to them not wanting to put their distro signature (or perhaps worry about license issues in doing so) on some 3rd party (non open) binary.

As I understand things, this is beyond the strict “UEFI Secure Boot” definition, and on to what OS-centric post-UEFI Secure Boot security techniques it will implement. I guess some call it “OS Secure Boot” to differentiate it from “UEFI Secure Boot”, but I don’t see any formal definition for that term.

I wish there was more precise information about Secure Boot implementation from each Linux distro. System administrators and technical support engineers will need to know these nuances, as will security researchers. Pehaps Linux Foundation or UEFI Forum — or some Wikipedian(s) — could help with a comparison of Secure Boot on different OSes? Perhaps FWTS or CHIPSEC could have a test to check? Perhaps the UEFI Forum could note these nuances at their next plugfest, and setup test cases combinining Linux OSVs with a test case that loads dynamically load native OS drivers: perhaps using CHIPSEC as the test case may suffice, it loads a native helper driver.

So, don’t just look at if Secure Boot is enabled or not, look at what Linux OS you’re using, and how it implements Secure Boot. And remember attackers are also making this choice, and looking for your softer Linux targets, so be more careful when using those systems.


Updated information:

The reason this issue came up is that the researcher was using Intel CHIPSEC, which when run on Linux it uses a Linux kernel module. Unlike most drivers, which get loaded when OS initializes, then stay loaded, the CHIPSEC driver behaves differently. The CHIPSEC userland Python app compiles the kernel module, and loads the module when it starts, then unloads the driver when it finishes (because the driver enables risky things, see it’s warning.txt). On Fedora, this kind of CHIPSEC driver loading behavior will not work, with Secure Boot enabled, until you setup moklist and sign the module. By contrast with Fedora, on Ubuntu, CHIPSEC is able to load the unsigned driver without the user having to change anything (convenience). Here’s more information on how Fedora does it’s module signing process: