Created attachment 1517948 [details]
engine.log.xz

Created attachment 1517949 [details]
vdsm.log.xz

doesn't sound relevant to oVirt
is it a regresion from https://bugzilla.redhat.com/show_bug.cgi?id=1561128#c29 or is it just supposed to be like that for RHEL?

Hi,

I'm not sure what the problem is. Comment 0 states:

> [    0.675918] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' linked to '.system_keyring'
> [    0.675932] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to '.system_keyring'

That's the intended behavior.

Since addressing bug 1561128, the file
"/usr/share/OVMF/OVMF_VARS.secboot.fd" has been a varstore template that
comes with the following certificates pre-enrolled:

(1) Platform Key and first Key Exchange Key:
"Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert"

(2) second Key Exchange Key:
"Microsoft Corporation KEK CA 2011"

(3) first DB entry:
"Microsoft Windows Production PCA 2011"

(Windows 8 and Windows Server 2012 R2 boot loaders are signed with a chain
rooted in this certificate.)

(4) second DB entry:
"Microsoft Corporation UEFI CA 2011"

(To verify the "shim" binary, and PCI expansion ROMs with.)

The kernel boot log confirms items (3) and (4), that is, the DB entries.
This is the expected behavior.


... Is the report perhaps about the messages

> [    0.676011] MODSIGN: Couldn't get UEFI MokListRT

and

> [root@localhost ~]# mokutil --list-enrolled
> MokListRT is empty

?

That's a different question; the MOK (machine owner key) variables are
maintained by shim / mokutil / MokManager. The MOK-related variables are not
*required* if the platform firmware already provides the certificates that
the user expects. MOK is only needed if the user wants to enroll
certificates that are not pre-installed, but the platform firmware doesn't
offer a facility for this (or offers it with a problematic user interface
only).

In brief, mokutil and friends *can* be used in OVMF guests, if the user
intends to install *custom* certificates; however, for booting released
RHEL, Fedora and Windows OSes, with Secure Boot enabled, using mokutil and
friends is not *required*. To quote an earlier email I wrote elsewhere:

> Once you created the domain with UEFI, you can manage Secure Boot at two
> levels:
>
> - At the level described by the UEFI specification. That is a functional
> description and not a User Interface description, therefore all BIOS
> vendors implement the built-in firmware setup interface for SB
> differently. Many BIOS vendors don't provide any access at all. (OVMF
> provides a simple textual UI.) This is why "shim" and "mokutil" were
> invented in the first place (to inject another layer of indirection in the
> SB chain and delegate key management to a common set of Linux utilities
> with a uniform user interface.)
>
> - At the level provided by shim and mokutil. In this scenario (which
> applies to all the RHEL7 documentation too), it is assumed that the
> platform has the Microsoft certificates pre-enrolled, and that the
> firmware's own (built-in) interface is never used for SB management. The
> firmware accepts "shim" as trusted, and all the actual key management and
> verification is implemented in "shim" and "mokutil".
>
> It is recommended that virtual machine users that want Secure Boot simply
> create their domains against the "OVMF_VARS.secboot.fd" variable store
> template. Then they will get a UEFI domain that very closely resembles a
> current physical workstation with SB pre-enabled. Then they should use
> shim/mokutil for their SB management, the way our documentation already
> explains.

Hence, I'm suggesting NOTABUG for this BZ.

Thanks,
Laszlo

(CC: Javier)

Hello,

I think this is a duplicate of bug 1649270. My understanding is that even when no Machine Owner Keys were enrolled, the built-in shim vendor should be present in the MokList variable and mirrored to the kernel through MokListRT. In the output of the dmesg command from Comment 1, the "Red Hat Secure Boot" key seems to be missing.

(In reply to Javier Martinez Canillas from comment #7)
> Hello,
> 
> I think this is a duplicate of bug 1649270. My understanding is that even
> when no Machine Owner Keys were enrolled, the built-in shim vendor should be
> present in the MokList variable and mirrored to the kernel through
> MokListRT. In the output of the dmesg command from Comment 1, the "Red Hat
> Secure Boot" key seems to be missing.

Hi Javier

Thanks you for the information. I observe the same behavior on RHEL 7.6 VM 
[root@localhost yum.repos.d]# LANG=C dmesg | grep -i secure
[    0.000000] Secure boot enabled

[root@localhost yum.repos.d]# LANG=C systemctl -l status kdump
* kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-01-08 04:43:34 EST; 2 days ago
  Process: 3815 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
 Main PID: 3815 (code=exited, status=1/FAILURE)

Jan 08 04:43:34 localhost.localdomain dracut[5951]: ========================================================================
Jan 08 04:43:34 localhost.localdomain dracut[5951]: *** Creating initramfs image file '/boot/initramfs-3.10.0-957.1.3.el7.x86_64kdump.img' done ***
Jan 08 04:43:34 localhost.localdomain kdumpctl[3815]: Secure Boot is enabled. Using kexec file based syscall.
Jan 08 04:43:34 localhost.localdomain kdumpctl[3815]: kexec_file_load failed: Required key not available
Jan 08 04:43:34 localhost.localdomain systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE
Jan 08 04:43:34 localhost.localdomain kdumpctl[3815]: kexec: failed to load kdump kernel
Jan 08 04:43:34 localhost.localdomain kdumpctl[3815]: Starting kdump: [FAILED]
Jan 08 04:43:34 localhost.localdomain systemd[1]: Failed to start Crash recovery kernel arming.
Jan 08 04:43:34 localhost.localdomain systemd[1]: Unit kdump.service entered failed state.
Jan 08 04:43:34 localhost.localdomain systemd[1]: kdump.service failed.
[root@localhost yum.repos.d]#

Trying to use https://bugzilla.redhat.com/show_bug.cgi?id=1649270#c34 workaround, did not resolve my issue.

Hello Nisim,

I think you must have made a mistake when trying the workaround, or
something must be off in your environment. I've reproduced the symptoms
discussed thus far, up to and including comment 8. However, at that point,
the workaround from bug 1649270 comment 34 definitely works for me.

Make sure you use the following:
- kernel-3.10.0-957.el7.x86_64
- kernel-doc-3.10.0-957.el7.noarch

After installing the latter package, run

> # mokutil --import \
>     /usr/share/doc/kernel-keys/3.10.0-957.el7/kernel-signing-ca.cer

pick a password, reboot the VM.

Then, when the MOK management is offered while the firmware has control
during reboot, enter MOK management. Select the key, enter the password. Ask
MokManager to reboot.

At next boot, kdump should initialize fine. It certainly does for me.

In this worked-around state, I get:

> [    1.659482] Loading compiled-in X.509 certificates
> [    1.660837] Loaded X.509 cert 'Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87362bc7229d9f465321773dfd1f77a80'
> [    1.663469] Loaded X.509 cert 'Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b72e3852e2014c3a676fc8'
> [    1.665871] Loaded X.509 cert 'Red Hat Enterprise Linux kernel signing key: 7e560e30261e0bb395b8945e39a3b010e2b87465'
> [    1.668232] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' linked to '.system_keyring'
> [    1.670628] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to '.system_keyring'
> [    1.673290] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29c65f85c' linked to '.system_keyring'
> [    1.675716] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29c65f85c' linked to '.system_keyring'

(note the duplicate "Red Hat Secure Boot (CA key 1)" cert -- that's the
result of the workaround. One instance comes from the shim built-in, another
from the mokutil --import command). Plus:

> # keyctl list %:.system_keyring
> 6 keys in keyring:
> 448760505: --alswrv     0     0 asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87362bc7229d9f465321773dfd1f77a80
> 362435039: --alswrv     0     0 asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29c65f85c
> 922842324: --alswrv     0     0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
> 455960900: --alswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
> 439729461: --alswrv     0     0 asymmetric: Red Hat Enterprise Linux kernel signing key: 7e560e30261e0bb395b8945e39a3b010e2b87465
> 942732749: --alswrv     0     0 asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b72e3852e2014c3a676fc8

The fact that "Red Hat Secure Boot (CA key 1)" is in the system keyring is
why "kexec_file_load" succeeds in loading
"/boot/vmlinuz-3.10.0-957.el7.x86_64". Namely,

> # pesign -l -i /boot/vmlinuz-3.10.0-957.el7.x86_64
> ---------------------------------------------
> certificate address is 0x7f7417861788
> Content was not encrypted.
> Content is detached; signature cannot be verified.
> The signer's common name is Red Hat Secure Boot (signing key 1)
> The signer's email address is secalert
> Signing time: Thu Oct 04, 2018
> There were certs or crls included.
> ---------------------------------------------

and "Red Hat Secure Boot (signing key 1)" chains to "Red Hat Secure Boot (CA
key 1)".

(In reply to Laszlo Ersek from comment #9)
Thanks.
Now it's working for me. 
For some reason I misses the MOK management blue screen after rebooting the VM.

(In reply to Nisim Simsolo from comment #10)
> (In reply to Laszlo Ersek from comment #9)
> Thanks.
> Now it's working for me.

Cool, thanks!

> For some reason I misses the MOK management blue screen after rebooting
> the VM.

That's a good point you raise there -- when I used MokManager for the very
first time, I missed that screen too.

Javier (and I'm sorry about going off-topic!), is it possible to invoke
"mokutil" in a way such that MokManager either have a (lot) longer timeout
after reboot, or that it block indefinitely, waiting for user input? If
there's now such method currently, would an RFE make sense from a design
POV?

... Oh wait, I've just found:

> commit 93708c11083f4ca28d53b7f32d23fff47ec1d761
> Author: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre>
> Date:   Thu Jul 5 11:28:12 2018 -0400
>
>     Let MokManager follow a MokTimeout var for timeout length for the prompt
>
>     This timeout can have the values [-1,0..0x7fff]; where -1 means "no timeout",
>     with MokManager going directly to the menu, and is capped to 0x7fff to avoid
>     unecessary long timeouts. The default remains 10, which will be used whenever
>     the MokTimeout variable isn't set.
>
>     Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre>

What is the preferred method for setting this variable? An "efivar"
invocation?

Thank you,
Laszlo

Unsigned kernel. Closing while we track SecureBoot elsewhere

(In reply to Laszlo Ersek from comment #11)
> (In reply to Nisim Simsolo from comment #10)
> > (In reply to Laszlo Ersek from comment #9)
> > Thanks.
> > Now it's working for me.
> 
> Cool, thanks!
> 
> > For some reason I misses the MOK management blue screen after rebooting
> > the VM.
> 
> That's a good point you raise there -- when I used MokManager for the very
> first time, I missed that screen too.
> 
> Javier (and I'm sorry about going off-topic!), is it possible to invoke
> "mokutil" in a way such that MokManager either have a (lot) longer timeout
> after reboot, or that it block indefinitely, waiting for user input? If
> there's now such method currently, would an RFE make sense from a design
> POV?
> 
> ... Oh wait, I've just found:
> 
> > commit 93708c11083f4ca28d53b7f32d23fff47ec1d761
> > Author: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre>
> > Date:   Thu Jul 5 11:28:12 2018 -0400
> >
> >     Let MokManager follow a MokTimeout var for timeout length for the prompt
> >
> >     This timeout can have the values [-1,0..0x7fff]; where -1 means "no timeout",
> >     with MokManager going directly to the menu, and is capped to 0x7fff to avoid
> >     unecessary long timeouts. The default remains 10, which will be used whenever
> >     the MokTimeout variable isn't set.
> >
> >     Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre>
> 
> What is the preferred method for setting this variable? An "efivar"
> invocation?
>

Sorry Laszlo, I missed this comment before. Probably you already found the answer, but if not the correct way to set the MokTimeout variable is by using the mokutil --set-timeout option. See the following commit:

https://github.com/lcp/mokutil/commit/4b7bc090ec2
 
> Thank you,
> Laszlo

Best regards,
Javier

Thanks for the info!