UEFI enroll password for community kernel

English Install/Boot/Login
1

In my OpenSuse 15.1 I want to test several community kernels. Unfortunately whenever I install an other kernel than the standard one my laptop denies it and prompts to enroll the new kernel signature (blue menu). In this very moment it asks for a password which I don’t know. I even don’t know where the password should come from? If I only hit enter the laptop complains the password is too short. The laptop is a DELL one. I can disable Secure Boot and it is working but I am curious how I could solve this with Secure Boot enabled (I know it sucks, but it strikes me.)
I assume the password is meant the one which was used for signing, but I think there is no password isn’t it?

Thanks for any hints
Thomas

2

Hi and welcome to the Forum :slight_smile:
In this case it’s the root user password since it’s the openSUSE Mokmanager utility running…

3

Just a bit more detail.

Kernels are not packaged with the signing key. And a request is made to MokManager, to enroll the new signing key. I think that is done with the “mokutil” command (there’s a “man” page for that command). And the enroll request requires a password. In this case, as Malcolm indicated, it is asking for the root password.

The certificate that is being enrolled is probably in “/etc/uefi/certs”.

4

Secure boot is always enabled here with stock Kernel, dual boot or not. We get a new kernel twice a week.
It is not rare that we have to boot in MoK to sign Linux Kernel modules or for a Grub update.

There are two types of question in that blue screen or MokManager when Secure Boot is enabled:

  1. A new Kernel and not always may ask to enroll the new Key. Just click continue to reboot to enroll it*.
  2. A Grub update comes with another type of message, but you have a clear indication on how to enroll the Key.

In both cases, avoid entering into other places in MoK, *opensuse applies a minimum change in that area.

-Root password is always asked when the machine boots in Mok by itself. If not working, try 12345678.

Make sure that entering Mok comes from a new Kernel or a Grub update=from opensuse, because you may have to deal with some malware instances.

So, check for incoming updates in the terminal, more specifically, for Grub (every 3 months on average) and/or a new Kernel that you compile by yourself or from regular updates.

A fresh install is another reason why the computer boots in MoK, but it implies a new Kernel or Kernel repo+ is enabled.

mokutil  --help

If for some reason(s) MoK gets contaminated or in a no end loop, run the following cmd line or disable secure boot and run it after:

mokutil  --reset

For security reasons, all of this is because Microsoft owns secure boot and let no one play there easily.

Check Secure Boot State

mokutil  --sb-state

See the opensuse Keys or any other distros:

mokutil  --list-enrolled

https://www.rodsbooks.com/efi-bootloaders/secureboot.html

5

You need to set password in advance using “mokutil --password”. It is possible to tell it to reuse existing root password using “mokutil --password --root-pw”. After reboot you will need to confirm this password again as verification before MokManager stores it permanently.

How pray a program running at boot time without any access to OS root filesystem is supposed to know root password (hash)?

6

On Thu 06 Jun 2019 04:26:03 AM CDT, arvidjaar wrote:
<snip>

malcolmlewis;2904591 Wrote:
> In this case it’s the root user password since it’s the openSUSE
> Mokmanager utility running…
How pray a program running at boot time without any access to OS root
filesystem is supposed to know root password (hash)?

Hi
My assumption is it’s written to MokManager.efi file…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
Tumbleweed 20190604 | GNOME Shell 3.32.2 | 5.1.5-1-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

7

Exactly!

Take good note that when the computer boots in MoK, it is because Opensuse applies changes to the EFI file. Just made a fresh install with secure boot enabled and did not even have time to enter the password.

The machine rebooted by itself after compiling Kernel 5.2-rc3. Took a few seconds.

Entering MoK to disable validation (disable secure boot momentarily) at boot time is another ball game, but you don’t have to that in Opensuse anymore,since MoK is/was simplified in favor of users.

Latest Kernel:

rpm -qa | grep -i kernel
kernel-firmware-20190514-260.1.noarch
kernel-source-5.2.rc3-1.1.g038ee83.noarch
patterns-devel-base-devel_kernel-20170319-8.3.x86_64
kernel-default-5.2.rc3-1.1.g038ee83.x86_64
kernel-macros-5.2.rc3-1.1.g038ee83.noarch
kernel-default-devel-5.2.rc3-1.1.g038ee83.x86_64
kernel-syms-5.2.rc3-1.1.g038ee83.x86_64
kernel-devel-5.2.rc3-1.1.g038ee83.noarch
kernel-default-5.1.7-3.1.gd7120e1.x86_64
mokutil  --sb-state
SecureBoot enabled


uname -a
Linux linux-1411 5.1.7-3.gd7120e1-default #1 SMP Tue Jun 4 09:13:54 UTC 2019 (d7120e1) x86_64 x86_64 x86_64 GNU/Linux

rpm -qa | grep -i gcc
gcc9-info-9.1.1+r271393-1.2.noarch
gcc-info-9-1.2.x86_64
gcc-c++-9-1.2.x86_64
gcc9-c++-9.1.1+r271393-1.2.x86_64
gcc9-9.1.1+r271393-1.2.x86_64
libstdc++6-devel-gcc9-9.1.1+r271393-1.2.x86_64
gcc-9-1.2.x86_64
libgcc_s1-9.1.1+r271393-1.2.x86_64

All the best,

8

My assumption has been that something is written to NVRAM.

9

Hi
I could very well be and stored as a hash (AFAIK the same one as /etc/shadow), turn off secure boot, boot an efi shell and inspect the nvram contents…

10

Hi,

indeed the root password was helpful in this case. I never would have thought it could be this password because the interface looked so simple and native. Maybe it is wise to make the mockutil to look more Linux originitated. It is a bit scary to enter the root password in this stage of the boot process. Thanks for all your helpful posts.

This leads to another question, as I understand it might be possible to circumstance this by issuing the mockutil after installing a new kernel, isn’t it? What is the correct procedure then and might it not be helpful to integrate this into the kernel install post script for all vendors of kernels?

BR
Thomas

11

There is no procedure, MoKManager is part of OpenSUSE and there aren’t much to do:

/boot/efi/EFI/opensuse/MokManager.efi

Unless there’s a Grub update, you have no password to enter, just let it go. Enrollment is made automatically.

A clean install cleans/clears the EFI partition sector in Windows. To do so, the following will set it back to default (factory setting/dual boot or not).

1.Delete the Tumbleweed partitions in Mini Tool Partition Wizard
2.Keep the remaining partition to unallocated for the next clean install
3.Open Command Prompt as root and run these cmd lines:

mountvol U: /s

del/f /s /q U:\*.*

bcdbootC:\Windows

Restart

Will update the thread on our next clean install to show the result.

On next clean install, after compiling the mainline Kernel, the machine will boot in MoK and the process is automatic. That’s it!

In Tumbleweed, all of this is/was simplified in favor of users to keep secure boot enabled. In Debian, it is another ball game, but let stick to Tumbleweed because it is the best place for testing the latest Kernel. On top, we get a correction(s) in the middle of the week.

rpm-qa | grep -i kernel 
**kernel**-default-5.1.7-4.1.gc8cc0ca.x86_64
**kernel**-syms-5.2.rc4-1.1.gc8bdb02.x86_64
**kernel**-devel-5.2.rc4-1.1.gc8bdb02.noarch
**kernel**-syms-5.2.rc3-3.1.gb4eda05.x86_64
**kernel**-firmware-20190514-260.1.noarch
**kernel**-source-5.2.rc4-1.1.gc8bdb02.noarch
**kernel**-default-5.2.rc4-1.1.gc8bdb02.x86_64
**kernel**-devel-5.2.rc3-3.1.gb4eda05.noarch
**kernel**-source-5.2.rc3-3.1.gb4eda05.noarch
**kernel**-macros-5.2.rc4-1.1.gc8bdb02.noarch
**kernel**-default-5.1.8-3.1.ged4965b.x86_64
patterns-devel-base-devel_**kernel**-20170319-8.3.x86_64
**kernel**-default-5.2.rc3-3.1.gb4eda05.x86_64
**kernel**-default-devel-5.2.rc4-1.1.gc8bdb02.x86_64
**kernel**-default-devel-5.2.rc3-3.1.gb4eda05.x86_64


mokutil--sb-state 
SecureBoot enabled

Enabling Mainline Kernel Repo. Prior to this, Linux Kernel Development was selected during the fresh install:


su -
zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
zypper dist-upgrade -r kernel-repo

All the best,

LatestKernel / Stable/ Unstable

12

Firstly – it is “mokutil”, not “mockutil”. Nothing is being mocked. The “mok” stands for “Machine Owner Key”.

There is actually a man page:

man mokutil

which gives details on how to use the command. My spelling correction is because you need to spell it correctly to use the man page.

If you look in “/boot/efi/EFI/opensuse”, you will see that there is a file “MokManager.efi”. That’s a little program that can interact with the UEFI firmware during boot. And it does most of the work. What “mokutil” does, is leave a list of tasks for MokManager to do when you next boot.

The original idea was that you might want to compile your own kernel. And if you are using secure-boot, then you will need to create your own signing key, and sign that kernel. And then you need to add your key to the firmware (using MokManager), so that the signature is recognized. There’s actually a web page explaining that:
openSUSE:UEFI. Scroll down to the heading “Booting a custom kernel”, where it explains the steps for creating your own key and signing a kernel.

For consistency, openSUSE is using the same procedure for the openSUSE keys. If you look in the directory “/etc/uefi/certs” you will find the keys used. There probably at least one file there. When a new certificate is added, MokManager needs to install that in the firmware NVRAM for it to be used. And “mokutil” communicates that to MokManager.

If you are adding your own key, you are prompted for a password to use. You are prompted by “mokutil” when you ask it to add a key. Then, on the next boot, MokManager requires that key before it will add the key. When you installed a kernel from the kernels repo, that does the same sort of thing. But it isn’t nice to demand a key in the middle of a package install. So, instead, installing a kernel from the kernels repo tells “mokutil” to use the root key.

I guess, after installing that kernel, you could tell “mokutil” to cancel the request to add that key. Then you could manually request that it add the key, and specify a password that you want to use. But that seems too complitated, when the current method works.

13

That made me curious. Indeed, kernel packages created using standard SUSE spec (at least those inside Kernel repository) do sign kernel, include certificate used to sign them as part of kernel package (in /etc/uefi/certs) and call “mokutil --import “$cert” --root-pw” in their postinstall script.

P.S. of course we have no idea whether this applies in this case because we know only some vague “community kernel” description which can refer to anything.

P.P.S. This means installing kernels from SUSE repository will - silently and without prior user knowledge and consent - copy root password hash into NVRAM. Arguably this adds additional attack vector as it may allow someone physically present on console obtain password hash. This especially is of concern to someone who uses full disk encryption …

14

Hmm. Mainline Kernel is an unsigned Kernel and it won’t compile if secure boot is enabled. A message is displayed at boot with the following errors:

  1. You must load the Kernel first
  2. Invalid signature

At this point of no return, the machine freezes and a cold shutdown must be made.

MoK signs the Kernel and allows the machine to boot a new cycle one. That does not implies any password. The rest belongs to Opensuse coders and engineers.

When someone decides to test Mainline Kernel, secure boot becomes a supplementary challenge and a second test pattern that implies MoK. We are trusting at 120% the server, we talk to, because it is the only one that boots in MoK.

Second patch of Release Candidate Four 20190611:

uname -a
Linux linux-0zue 5.2.0-rc4-2.gad82a9a-default #1 SMP Tue Jun 11 05:18:31 UTC 2019 (ad82a9a) x86_64 x86_64 x86_64 GNU/Linux

All the best,

NB From memory, the only time we’ve entered the root password, it was for a Grub update. Never after a fresh install, just sit and wait the MoK delay to complete.

15

Hi,

as the OP I want to give some more background here and describe the exact observations.
I tested several kernels from two community repos and both were not signed in any way. This resulted in a MokManager boot as described in my first post. (It was absolutely not visible where this manager comes from nor which password was requested). When I failed enrolling the kernel the system did stall at Grub claiming the signature not present for the kernel. (nor any hint was made that the MokManager might be able to resolve my problem.) However the Mokmanager did not appear again, also after cold reset, even if the non booting kernel was still present.
This was tested with a standard install of 15.1.

The community kernels for 15.1 can be found here: https://software.opensuse.org/package/kernel-desktop

I also did read the kernel signing manual but it was not working as described (I assume some changes here with newer systems): https://en.opensuse.org/openSUSE:UEFI

It is still not clear to me if the vendor of the kernel can improve the installation, I was in contact with one vendor but he could not help me out. So I would like to give him a hint how to cook a kernel and most important if he could do some kind of post install processing to avoid this in future.

BR
Thomas

PS: I don’t want to blame here, I know the source of all these problems and want I to give back some feedback in the hope it will help the community.

16

How do you know it? I downloaded random community kernel:

bor@bor-Latitude-E5450:~/Загрузки/k$ sbverify --cert ./etc/uefi/certs/2EED1B60.pem boot/vmlinuz-4.19.49-lp151.1-desktop
Signature verification OK
17

That is rather presumptuous after all this thread.

18

That was the only package today. Let’s hope that it won’t get worse, there is no bug with mok manager here and no password to deal with. It is an automated enrollment process.

dup

pesign-obs-integration - Macros and scripts to sign the kernel and bootloader

This package provides scripts and rpm macros to automate signing of the boot loader, kernel and kernel modules in the openSUSE Buildservice.

19

Folks your are really funny:

However I am too old not to know how to deal with. But many thanks anyway for all the input.

Have a nice day
Thomas

20

Hi Mike, what exactly you want to say with this? Is it the responsibility of the kernel vendor to deal with it? I understand it like this: A community kernel should not make the MokManager popup in any way if equipped with a valid signature.

BR
Thomas