Debian UEFI Secure Boot report from DebConf

DebConf, the Debian conference is happening, and there’s a EFI Secure Boot talk. Slides are listed on the debian-efi list below:

https://lists.debian.org/debian-efi/2018/07/msg00015.html

https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/?

 

Secure Boot BOF at DebConf17

Helen Koike of Collabora has proposed a BOF on UEFI Secure Boot at DebConf17, this August:

DebConf17 – BoF proposal to discuss secure boot
I want to send a BoF proposal to DebConf17 so we can meet there and discuss about secure boot. I would like to know if you are interested in attending and also which topics you suggest for discussion. I would appreciate if you could put your name and suggestions in this form in case you are interested https://goo.gl/forms/lHoEibY1H6FmSHSJ2 , or just reply to this email thread.

For full message, see the debian-efi mailing list archives.

https://lists.debian.org/debian-efi/2017/05/threads.html

https://docs.google.com/forms/d/e/1FAIpQLSdtHYNy9212iXP26tkjbb6XvgVSMjJzn2DYoAilFT1l89vemw/viewform?c=0&w=1

https://debconf17.debconf.org/

 

 

DebConf16

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.

https://bits.debian.org/2016/06/debconf16-schedule.html
https://debconf16.debconf.org/

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.
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.
https://debconf16.debconf.org/talks/79/

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”?
https://debconf16.debconf.org/talks/33/

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.
https://debconf16.debconf.org/talks/10/

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).
https://debconf16.debconf.org/talks/119/

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.
https://debconf16.debconf.org/talks/90/

Andy Simpkins: Developing products in the open

Last month, at the DebConf, the annual Debian conference, there was a talk for OEMs on using Open Source Software and Free Software (FOSS), as well as using Open Source Hardware. Most have heard an Open Source advocate discuss the merits of open-source -vs- closed-source software. This talk is from the perspective of vendors who need to buy and build hardware.

Developing products in the open
Andy Simpkins
Over the last couple of decades the world of product development with embedded systems has changed considerably. Changing to Open Source (for hardware as well as software) is not easy. The world resists change, this is a brief history of where I have succeeded, where I have failed and the lessons learned. This is a not a technical talk, more a collection of observations.

The video can be downloaded in WBEM format from DebConf site, or watched online via Youtube:

http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/
https://summittest.debconf.org/debconf15/meeting/192/developing-products-in-the-open/
https://summit.debconf.org/debconf15/meeting/192/developing-products-in-the-open/
http://debconf15.debconf.org/
https://www.youtube.com/watch?v=8rDvnnCMJfk