1

I am on Ubuntu 16.04 with the 4.4.0-57 kernel and I want to install a self-made module. The BIOS is a non UEFI BIOS (Kontron 986LCD-M/mITX).

I tried to sign the module by following this procedure but the result of step 3 (sudo mokutil --import MOK.der) is EFI variables are not supported on this system.

I tried to follow this recipe but I cannot find the public keys.

How can I sign a module on a non UEFI board?

====================================================

Update 1: It seems to be a fairy tale that only modules running with a UEFI Bios have to use signed modules under 16.04:

I use as grub option: `GRUB_CMDLINE_LINUX=" acpi_enforce_resources=lax"`. 

I get the error `module verification failed: signature and/or required key missing - tainting kernel` in dmesg if I try to load a module via modprobe.

`sudo mokutil --disable-validation` returns the error `EFI variables are not supported on this system`

================ Update 1 ===================================================

I am sorry but this statement is wrong:

The procedure to which you refer describes disabling Secure Boot validation, not signing modules. There's no need to sign kernel modules on non-UEFI systems, since Secure Boot is exclusively a UEFI feature.

The kernel should work in this way it doesn't. I experiance it because I get always the error message I get the error module verification failed: signature and/or required key missing - tainting kernel in dmesg and the kernel is not loaded.

================ Update 2 =================================================== How can I install shim on a non uefi motherboard:

# aptitude search shim
p   grub-splashimages                                   - a collection of great GRUB splashimages
p   grub2-splashimages                                  - a collection of great GRUB2 splashimages
p   libjs-es5-shim                                      - ECMAScript 5 compat. shims for old JavaScript engines (library
p   libjs-es6-shim                                      - ECMAScript 6 compat. shims for legacy JavaScript engines (libr
p   node-es5-shim                                       - ECMAScript 5 compat. shims for old JavaScript engines (Node.js
p   node-es6-shim                                       - ECMAScript 6 compat. shims for legacy JavaScript engines (Node
p   olpc-kbdshim                                        - Dienst zur OLPC-XO-Tastaturunterstützung
v   olpc-kbdshim-common                                 -
v   olpc-kdbshim-hal                                    -
p   ruby-launchy-shim                                   - helper class for launching a web browser
p   shimmer-themes                                      - Gtk+ themes from Shimmer Project
p   shimmer-wallpapers                                  - Wallpapers from Shimmer Project
p   systemd-shim                                        - shim für systemd
p   yoshimi                                             - Software-Synthesizer, basiert auf ZynAddSubFX
p   yoshimi-data                                        - Voreinstellungen für Yoshimi

Is systemd-shim correct? I believe that it will not work because it is a non-uefi MB...

Community
  • 1
musbach
  • 1,505

2 Answers2

1

It is a huge bug in Ubuntu. mokutil and MokManager can only sign your own modules if you have MB which support uefi. Older MB under Ubuntu 16.04 which do not support uefi cannot sign modules with mokutil and MokManager. You will get always a responds like EFI variables are not supported on this system or similar.

It is claimed that the signing is just enabled by the kernel for uefi MB. I'm sorry but this is wrong. This is also shown e.g. by these kernel parameter:

CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_UEFI=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_CHECK_SIGNATURE=y
CONFIG_SIGNATURE=y

As I said this are the kernel parameter for a non uefi MB which don’t make sense, especially CONFIG_MODULE_SIG_UEFI=y.

You have to recompile the kernel and switch off the signing options. They can be found by grep -v ^# /boot/config-$(uname -r) | grep _SIG. Especially CONFIG_MODULE_SIG and CONFIG_MODULE_SIG_ALL should be set to n. However, this has a clear disadvantage because you have to put the kernel update on hold and you’ll have to recompile every new kernel. It’s frustrating.

-1

The procedure to which you refer describes disabling Secure Boot validation, not signing modules. There's no need to sign kernel modules on non-UEFI systems, since Secure Boot is exclusively a UEFI feature.

That said, if you did want to sign kernel modules on a non-UEFI system, you should be able to do so. (I've not tried it, but AFAIK all the tools are Linux userspace tools that do not rely on Secure Boot being available or active.) You might do this if you wanted to build a package with signed modules for installation on other systems. Note that you'll need to install your own keys on the target systems, which can be tedious; see below for pointers. To sign kernel modules:

  1. Create a set of signing keys. This is a complex task. I recommend you read my page on Secure Boot for information on creating signing keys.
  2. Locate the sign-file binary. This binary is not normally installed where Linux binaries are installed; instead, it comes with kernel headers. The command find /usr/src/ -name sign-file should locate it if it's installed on your system. If this command returns nothing, you must install a kernel headers package.
  3. Sign the binary with a command like /path/to/sign-file sha256 /key/path/your.key /key/path/your.cer /path/to/module/module.ko

At this point, the binary module.ko will be signed with your key (your.key and your.cer). To be used, your key must be registered with the target system, presumably in the MOK list. To do this, you must install it with MokManager.efi, as detailed on my Secure Boot page.

I'd like to emphasize again, though, that signing kernel modules is not necessary except on systems that are booting in UEFI mode with Secure Boot active -- and even then, it's necessary only for third-party or locally-compiled kernel modules, such as commercial video drivers or the VirtualBox kernel modules. Most of the kernel modules provided with the Ubuntu kernel are already signed with the same Canonical key that's used to sign GRUB and the main Ubuntu kernel file.

Rod Smith
  • 45,120
  • 7
  • 66
  • 108