If you install Ubuntu on a computer with secure-boot enabled, then it will probably boot. And maybe that’s all you want.
If so, you probably won’t be concerned about what I am describing here.
However, secure-boot is supposed to verify many of the steps in the boot path. And that’s where I see Ubuntu as broken.
I’m basing this on tests that I have done on Ubuntu-17.04 and Ubuntu-gnome-17.04.
First a brief summary of the problems that I am seeing:
- Ubuntu will boot without checking a signature on the kernel.
- Under some circumstances, Ubuntu will complain about a bad signature, and refuse to boot, even though secure-boot has been disabled.
[update: please check the comments]
I finally got around to signing a kernel. That went pretty well. So I thought that I would describe what I did.
This post presupposes a little knowledge of digital certificates. If you are looking for a quick introduction, try my post on my other blog.
My test machine has opensuse Tumbleweed. But it also has Mint 17.1 (updated from the Mint 17 that I installed). UEFI booting has been working well with Tumbleweed. But I installed Mint without secure-boot support, so I had to leave secure-boot disabled to boot it.
In more detail, I installed Mint in legacy MBR booting mode, because I did not want to clutter the UEFI name space. That worked fine. I could then UEFI boot it anyway, either with the generated grub menu for Tumbleweed or with a “configfile” command that I added to that menu. But secure-boot did not work, because the installed Mint kernel was not signed by an accepted key (it was not signed at all, it seems).
It is now a little over two years since I first acquired a computer with UEFI support. That was a Dell Inspiron 660. It came with Windows 8 (since upgraded to Windows 8.1). I have left secure-boot enabled for most of that time, “to keep Windows happy”. In fact Windows does not complain at all if I disable secure-boot.
My second UEFI box is almost one year old. I do not have Windows installed there. It is a Lenovo ThinkServer TS140. When I first purchased it, secure-boot did not work all that well so I left it off most of the time. I did turn it on for some testing, but it required modifying the opensuse “shim” to get it to work. The problem that I had with secure-boot is described here under the heading “Booting the Machine that supports only one signature with vendor provided Keys”. After a BIOS update a few months ago, secure-boot now works quite well on the TS140, so recently I have been leaving it enabled most of the time.
When my desktop computer failed, I could still fall back to using my laptop. But I wanted to get back up and running with a desktop, which I find more congenial to use. I could just use my UEFI box. However, my old desktop was also being used to support some network file sharing (NFS on opensuse and samba for Windows). I could set that up on the new box, but it would take a while.
The simplest strategy seemed to be to take the disk from the failed box, install in a hard drive enclosure, and access that as a USB disk. I already had a suitable hard drive enclosure. Removing the disk from the failed computer, and installing in the enclosure was simple enough. Read More…
There has been some discussion of secure boot in various forums on the internet. The basic idea is that newer hardware, with UEFI partition, allows secure boot. With secure boot, an operating system will not be allowed to boot unless it has a verifiable digital signature.
Related to this, Microsoft has insisted that it won’t certify hardware for use with Window 8, unless it supports secure boot. Some have seen this as a diabolical scheme by microsoft to assert monopoly control and lockout the use of linux. Other, calmer minds, have suggested that maybe secure boot is actually a good idea, even for linux. And that open source software users should be looking for ways to use secure boot instead of opening up a new front in the operating system religious wars. Read More…