Email: email@example.com • Twitter: @benhutchingsuk • Debian: benh • Gitweb: git.decadent.org.uk • Github: github.com/bwhacks
I was assigned another 15 hours of work by Freexian's Debian LTS initiative and carried over 5 from last month. I worked a total of 19 hours, carrying over 1.
I spent a week in the Front Desk role and triaged many new security issues for wheezy.
I prepared the Linux 3.2.81 stable update, sent it out for review and finally released it. I then rebased the wheezy-security branch on top of that and added some later security fixes that were not yet suitable for a kernel.org update. I uploaded to wheezy-security and issued DLA-516-1.
I started working on the next Linux stable updates (3.2.82 and the next wheezy LTS update) and on an update for imagemagick, but haven't uploaded anything for them yet.
I was assigned another 15 hours of work by Freexian's Debian LTS initiative, but only worked a total of 10 hours. I intend to make up for this in June.
I began preparing the next stable update for Linux 3.2 on kernel.org, but haven't yet sent it out for review. I rebased the wheezy-security branch onto Linux 3.2.80, and added fixes for one more security issue and one data corruption issue affecting aufs.
I started a week in the front desk, triaging new issues for wheezy.
On 1st May 2006 my Debian account was created and I gained the status of Debian Developer. At that time I had already been to several BSPs and one DebConf, and maintained a few applications and Perl library packages. We were working toward the etch release and would soon hold DebConf 6 in Mexico.
Ten years later, I still maintain one of those packages (sgt-puzzles) but the rest were either handed over to the Perl team or entirely removed. I wrote, maintained, and then gave away dvswitch all within this period. I have packaged some other applications that I needed to use - kup, ministat, odhcp6c - and I continue to maintain them. I have also made many NMUs, including security uploads, for all kinds of packages including bind9, e2fsprogs, (e)glibc, lvm2, sudo, sysvinit and udev.
However, for about the past 7 years most of my work in Debian has been done within the kernel team, working on the Linux kernel and closely related packages - such as crda, ethtool, firmware-nonfree and initramfs-tools. I have also become an upstream developer for several of these projects.
I'm proud to have played a part in the etch, lenny, squeeze, wheezy
and jessie releases, and I have enjoyed attending 7 more DebConfs
and many mini-DebConfs. I'm now looking forward to another great
release (stretch) and to attending DebConf 16 in Cape Town
summer . I hope to still be active
in Debian in 2026, looking back on another 10 years in this amazing
This month was still quiet for me in terms of uploads, as "wheezy" was only handed over to the LTS team near the end of the month. I carried over 5.5 hours from March and was assigned another 15 hours of work by Freexian's Debian LTS initiative, but only worked a total of 12.25 hours. I have returned the spare hours to the pool.
As last month, I prepared a stable update for Linux 3.2 on kernel.org, which will be released soon as 3.2.80. I also triaged the open security issues and backported a few individual patches to our wheezy-security branch. However I expect to rebase the wheezy-security branch onto Linux 3.2.80 before making the next upload.
I also participated in discussion of supporting armel/armhf in wheezy LTS. I don't expect many LTS users to be using the Debian kernel packages, as we only supported a small range of ARM hardware before the introduction of the multiplatform flavours in jessie. However, those architectures rarely require any extra effort to support in linux stable updates so I had no objection to including them.
I've lately been working on support for Secure Boot in Debian, mostly in the packages maintained by the kernel team.
My instructions for setting up UEFI Secure Boot are based on OVMF
running on KVM/QEMU. All 'Designed for Windows' PCs should allow
reconfiguration of SB, but it may not be easy to do so.
also assume that the firmware includes an EFI shell.
Updated: Robert Edmonds pointed out that the 'Designed for Windows' requirements changed with Windows 10:
The ability to reconfigure SB is indeed now optional for
which are designed to always boot with a specific Secure Boot
configuration. I also noticed that the requirements say that
OEMs should not sign an EFI shell binary. Therefore I've
revised the instructions to use efibootmgr instead.
UEFI Secure Boot, when configured and enabled (which it is on most new PCs) requires that whatever it loads is signed with a trusted key. The one common trusted key for PCs is held by Microsoft, and while they will sign other people's code for a nominal fee, they require that it also validates the code it loads, i.e. the kernel or next stage boot loader. The kernel in turn is responsible for validating any code that could compromise its integrity (kernel modules, kexec images).
Currently there are no such signed boot loaders in Debian, though the shim and grub-signed packages included in many other distributions should be usable. However it's possible to load an appropriately configured Linux kernel directly from the UEFI firmware (typically through the shell) which is what I'm doing at the moment.
Signing keys obviously need to be protected against disclosure; the private keys can't be included in a source package. We also won't install them on buildds separately, and generating signatures at build time would of course be unreproducible. So I've created a new source package, linux-signed, which contains detached signatures prepared offline.
Currently the binary packages built from linux-signed also contain only detached signatures, which are applied as necessary at installation time. The signed kernel image (only on x86 for now) is named /boot/vmlinuz-kversion.efi.signed. However, since packages must not modify files owned by another package and I didn't want to dpkg-divert thousands of modules, the module signatures remain detached. Detached module signatures are a new invention of mine, and require changes in kmod and various other packages to support them. (An alternate might be to put signed modules under a different directory and drop a configuration file in /lib/depmod.d to make them higher priority. But then we end up with two copies of every module installed, which can be a substantial waste of space.)
The packages you need to repeat the experiment:
For Secure Boot, you'll then need to copy the signed kernel and the initrd onto the EFI system partition, normally mounted at /boot/efi.
SB requires a Platform Key (PK) which will already be installed on a real PC. You can replace it but you don't need to. If you're using OVMF, there are no persistent keys so you do need to generate your own:
openssl req -new -x509 -newkey rsa:2048 -keyout pk.key -out pk.crt \ -outform der -nodes
You'll also need to install the certificate for my kernel image signing key, which is under debian/certs in the linux-signed package. OVMF requires this in DER format:
openssl x509 -in firstname.lastname@example.org \ -out linux.crt -outform der
You'll need to copy the certificate(s) to a FAT-formatted partition such as the EFI system partition, so that the firmware can read it.
Use efibootmgr to add a boot entry for the kernel, for example:
efibootmgr -c -d /dev/sda -L linux-signed -l '\vmlinuz.efi' -u 'initrd=initrd.img root=/dev/sda2 ro quiet'
You should use the same kernel parameters as usual, except that you also need to specify the initrd filename using the initrd= parameter. The EFI stub code at the beginning of the kernel will load the initrd using EFI boot services.
If all went well, Linux will boot as normal. You can confirm that Secure Boot was enabled by reading /sys/kernel/security/securelevel, which will contain 1 if it was.
Module signatures are now always checked and unsigned modules will be given the 'E' taint flag. If Secure Boot is used or you add the kernel parameter module.sig_enforce=1, unsigned modules will be rejected. You can also turn on signature enforcement and turn off various other methods of modifying kernel code (such as kexec) by writing 1 to /sys/kernel/security/securelevel.