Ben Hutchings

Debian now has gcc and binutils packages for cross-building with a variety of build and host architectures. They still don't do everything that some cross-toolchain users want. Let's discuss how to fill the gaps.

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"?

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.

Advantages:

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

Caveats:

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

The Linux kernel is under rapid development. Stable releases are made around 5 times per year, each including many new features and support for new hardware. This talk will summarise the features that have been added and enabled in the last year.

There have been many changes to Linux between 4.1 and 4.6. Some of these will require new or updated userland applications to take advantage of them. I will attempt to summarise the most interesting changes and the state of integration in Debian.