Secure Boot - linux-surface/linux-surface GitHub Wiki

This section details secure boot in combination with shim (usually provided via the shim-signed package). If you choose another method (e.g. via PreLoader), please refer to the instructions provided by your distribution. As of 2019-09-29, new binary kernel releases (for Debian and Arch Linux) will be signed with one of our secure boot certificates, to allow easier installation and updates.

The idea of secure boot is to only allow trusted software to boot on your PC, and thus lock out potential viruses and rootkits that would otherwise be undetectable by our operating system. As custom kernels, such as this one, can be built and distributed by anyone, they are considered not trustworthy by your bootloader, and thus, if you have secure boot enabled, won't be allowed to boot. Luckily there are methods to establish that trust with your bootloader, however, this also means that you have to go through some extra hoops. In the following, we will focus on shim, the default way to achieve this on Ubuntu, Debian, and Fedora. Please refer to the instructions provided by your distribution on how to set this up. Note that in some cases, this might already be set up for you. shim is a chainloader (usually) signed by Microsoft, meaning it is inherently trusted by your bootloader and can be used to load other EFI binaries (i.e. kernels) which it deems trustworthy. To tell shim that a kernel is trustworthy, we will, in the following, use signatures via public and private keys.

Using the Provided Secure Boot Certificate

For your convenience, future (as of 2019-09-29) binary kernel releases will be pre-signed with one of our secure boot keys. You can find the corresponding public key here: linux-surface/linux-surface/keys/MOK.cer

If you use/plan to use secure boot, please make sure that you have enrolled this key before attempting to boot the signed kernel. To help you enroll this key, we provide packages (linux-surface-secureboot-mok for Debian and Arch Linux based distributions or surface-secureboot for Fedora based distributions) in the corresponding package repositories, which install the key and guide you through the enrollment process. To use the automated setup, you must have secureboot enabled when installing the package. This likely means that you will have to boot into the kernel provided by your distribution for this step, if your distribution has secureboot set up already.

If you use Arch, or one of its derivates, you have to setup secureboot first, before you can enroll the linux-surface key. You need to install a signed shim binary from the AUR, generate a custom keypair to sign the bootloader with and enroll it before installing linux-surface-secureboot-mok. Please refer to the Arch Wiki entry about secureboot for more information.

Manually Enrolling a Public Key

To manually enroll a public key, we recommend using the mokutil tool (install mokutil-git for Arch Linux). Via this, you can manage your trusted secure boot certificates, e.g. view, enroll, or delete them. To enroll a public key, you need it in x509 DER format (the links above already provide this format). You can then enroll it using

sudo mokutil --import <key.cer>

During this, you will get asked for a password. You can freely choose it, but you will need to remember it to complete the process and manage your key. To finalize this operation, you need to reboot, which will then bring you to the MokManager tool. Here, you can finally enroll this key via the Enroll key option, which you need to confirm with your chosen password. Please make sure that this is indeed the key you want to enroll.

If you do not trust this key any more, you can delete/revoke it via

sudo mokutil --delete <key.cer>

You, again, need to choose a password and reboot to complete this operation inside the MokManager tool.

Note: mokutil may only work if you have secure-boot turned on. If you currently don't have secureboot turned on, you will have to copy the key you want to enroll to the EFI partition, reboot into MokManager, and add it manually.

Using your own Key Pair

Please note that this is not intended as an exhaustive tutorial, but rather as a quick overview of what to do. As always, please consult the instructions provided by your distribution in addition to this. To create your own keys you will need openssl, to sign your kernel you will need sbsign, usually provided by the sbsigntool package (sbsigntools on Arch Linux).

First, you will need to create your own public and private keys. The private key will be used to sign the kernel, whereas the public key will be used by shim to verify this signature. If you do not know anything about public and private key cryptography, please note that the private key is, as the name implies, to be kept private. If you have enrolled the corresponding public key, anyone with this private key can sign kernels that will then be allowed to boot on your system. In short, handing over your private key is like handing over your passport.

To create the key pair, run

openssl req -new -x509 -sha256 -nodes \
    -newkey rsa:4096 \
    -days 3650 \
    -subj "/CN=my Machine Owner Key/" \
    -out MOK.crt \
    -keyout MOK.key

You may want to adapt the output file names, subject line, and duration of validity (days) to your liking. To use the public key with mokutil, you next need to convert it to DER form via

openssl x509 -outform DER -in MOK.crt -out MOK.cer

You should now enroll this key as described in "Manually Enrolling a Public Key", however, you can delay the restart until after you have signed the kernel. To finally sign the kernel, run

sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-[KERNEL-SUFFIX] /boot/vmlinuz-[KERNEL-SUFFIX]

where [KERNEL-SUFFIX] is the version and suffix of the kernel you want to sign.

If you have not done so before installing the kernel, update your bootloader config (e.g. for GRUB run sudo update-grub), reboot, and finish the key enrollment process if not completed already. Please note that you will need to re-run the sbsign command each time you update your kernel and thus you should keep your generated keys (MOK.key, MOK.crt, and MOK.cer) secure and safe.


For further information, you may want to look at the Arch Linux wiki entry or this Ubuntu blog entry.

⚠️ **GitHub.com Fallback** ⚠️