Ben Hutchings

The Linux kernel has a very active development community, constantly adding not only new hardware support but new features. Some of these features can simply be enabled by the configuration in the Debian package, but some also require support from other user-space packages. This talk will cover some of the more interesting changes made in the past year, and any work that’s still needed to support these in Debian.

The Linux kernel has a very active development community, constantly adding not only new hardware support but new features. Some of these features can simply be enabled by the configuration in the Debian package, but some also require support from other user-space packages. This talk will cover some of the more interesting changes made in the past year, and any work that’s still needed to support these in Debian.

The Linux kernel has a very active development community, constantly adding not only new hardware support but new features. Some of these features can simply be enabled by the configuration in the Debian package, but some also require support from other user-space packages. This talk will cover some of the more interesting changes made in the past year, and any work that's still needed to support these in Debian.

We use several different approaches to improve hardware support during a Debian stable release: - Updating selected drivers in the linux package - Adding newer versions of linux and other packages to the associated backports suite - Adding an alternate kernel version in the stable suite (etch-and-a-half, jessie LTS) Updating selected drivers in the linux package (and other driver packages) is the best way to make new hardware support available to users, but it can require substantial development time and carries a relatively high risk of regression. I did many kernel driver backports during the stretch and wheezy releases, but haven't found time to do so more recently. The backports suites can provide comprehensive support for new hardware, but they are less easily available (for example, there is no official installer build using the kernel from backports). The backports suites are often the last to get security updates, and they are not maintained during the LTS period. We've previously tried to add alternate kernel versions half way through a stable cycle, with limited success. For etch, the etch-and-a-half update added new versions of the Linux kernel, some X drivers, and the installer to etch shortly before the lenny release. For jessie, there were plans to improve Arm64 support in a similar way, but these were overtaken by the stretch release. How can we do better?

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.14 and 4.18. 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.

This talk is a report on the current status of the support of Secure Boot on Debian by the EFI team and what is missing. The team are going to explain the main architecture and workflow, the required changes in dak, how the signing service works and how this impacts packaging due to the new template binary packages required for the signing service.

Other people: Julien Cristau Tollef Fog Heen Luke W Faraone Ansgar Burchardt Helen Koike

There are various tools for creating system images based on Debian and its derivatives, including vmdebootstrap(2), bitbake, and live-wrapper. Each has its own pros and cons. This is an opportunity to share practical experience, including recommendations for effective usage, traps to avoid, and lesser-known tools for this task.

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.

Other people: Matthias Klose

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

Other people: nicoo

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

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.

Each Linux kernel release is followed by a series of stable updates fixing bugs, hosted at kernel.org. Linux distributions generally use these as a basis for their packages. I describe how the stable update process works and how distributions can be more involved.