action #164183
closed[Micro] [ Staging] Allow enrolling a test kernel in SecureBoot
0%
Description
Due to change in IBS, packages built in Staging project are no longer built with SUSE key. This causes breakage when using SecureBoot since grub & kernel are no longer signed with SUSE key, shim is refusing to load them.
Workaround 1 (already implemented): boot with Secure Boot disabled. This prevents testing Secure Boot feature and features which relies on SecureBoot working (Full Disk Encryption with TPM).
Workaround 2: enroll key used to sign kernel/grub2 into Secure Book MOK keyring:
- we need to make this key available on EFI boot partition and when we get "Verification failed: Security Violation" from shim:
- press enter twice to access enrolling
- Enroll key from disk
- choose the key on EFI partition
- accept the enrollment
- reboot the system
Another option would be to do the setup from above, power down the system, save the NVRAM / EFI variable partition, which will have the proper key enrolled and use this nvram setup directly to bypass the "security violation" prompt.
This should only be used for staging.
Updated by jlausuch about 1 month ago
- Subject changed from Allow enrolling a test kernel in SecureBoot to [Micro] [ Staging] Allow enrolling a test kernel in SecureBoot
- Status changed from New to Workable
- Priority changed from Normal to High
Updated by okurz about 1 month ago
- Project changed from openQA Project to openQA Tests
Updated by okurz about 1 month ago
- Related to action #164150: [SLFO] Stagings: official SUSE keys aren't used anymore added
Updated by jlausuch about 1 month ago · Edited
I have booted a job using the following:
UEFI_PFLASH_CODE=/usr/share/qemu/ovmf-x86_64-code.bin
UEFI_PFLASH_VARS=/usr/share/qemu/ovmf-x86_64-vars.bin
Booting now works, but zypper ref complains:
$ zypper -n refresh
Retrieving repository 'SL-Micro-6.1-Pool' metadata [.........Repository 'SL-Micro-6.1-Pool' is invalid.
[SUSE_Linux_Micro_6.1_x86_64:SL-Micro-6.1-Pool|http://openqa.suse.de/assets/repo/SL-Micro-Packages-6.1-x86_64-BuildV.6.1/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'SL-Micro-6.1-Pool' because of the above error.
Could not refresh the repositories because of errors.
New repository or package signing key received:
Repository: SL-Micro-6.1-Pool
Key Fingerprint: F5FE 65C3 163C D347 266C 583D 9C75 3149 CE3B 672E
Key Name: Unsupported <unsupported-rsa@suse.de>
Key Algorithm: RSA 2048
Key Created: Tue Feb 14 15:47:25 2023
Key Expires: Sat Feb 13 15:47:25 2027
Rpm Name: gpg-pubkey-ce3b672e-63ebad0d
Note: Signing data enables the recipient to verify that no modifications occurred after the data
were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
and in extreme cases even to a system compromise.
Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
you are not sure whether the presented key is authentic, ask the repository provider or check
their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
are using.
Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): r
error]
And if you try to use auto import keys:
$ zypper --gpg-auto-import-keys ref
Retrieving repository 'SL-Micro-6.1-Pool' metadata [.........
Automatically importing the following key:
Repository: SL-Micro-6.1-Pool
Key Fingerprint: F5FE 65C3 163C D347 266C 583D 9C75 3149 CE3B 672E
Key Name: Unsupported <unsupported-rsa@suse.de>
Key Algorithm: RSA 2048
Key Created: Tue Feb 14 15:47:25 2023
Key Expires: Sat Feb 13 15:47:25 2027
Rpm Name: gpg-pubkey-ce3b672e-63ebad0d
Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
you are not sure whether the presented key is authentic, ask the repository provider or check
their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
are using.
Subprocess failed. Error: Failed to import public key [9C753149CE3B672E-63ebad0d] [Unsupported <unsupported-rsa@suse.de>] [expires: 2027-02-13]
History:
- Command exited with status 1.
- error: /var/tmp/zypp.8l5Sq2/pubkey-9C753149CE3B672E-MSopej: key 1 import failed.
- error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)
..............done]
Building repository 'SL-Micro-6.1-Pool' cache [....done]
All repositories have been refreshed.
Updated by msmeissn about 1 month ago
I was thinking of one approach:
- in stagings only, build suse-build-key and include the current repokey.
- build installation-images to include this as trusted key
- build media
- build kiwi images also with suse-build-key
However, this does not work if only RPM-MD repos are built, like we have on SLE Micro 6.0 maintenance use-case.
There I think the best way is to auto import the staging key, either hardcoding of as Jose proposed a zypper ref --auto-import-keys
Updated by msmeissn about 1 month ago
For secure boot, you either can disable secure boot in stagings (but run in main repo), or implement handling the MOK import dialog.
Updated by jlausuch about 1 month ago · Edited
- Status changed from Workable to Resolved
- Assignee set to jlausuch
This addresses Marcus's comment.
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19782
Let's do it like this for now to unblock the current state.
msmeissn wrote in #note-6:
For secure boot, you either can disable secure boot in stagings (but run in main repo), or implement handling the MOK import dialog.
I think we can disable it for Stagings to keep them as simple as possible. Milestone job groups will handle that.
For Micro 6.1 Stagings, I will set /usr/share/qemu/ovmf-x86_64-code.bin
instead of /usr/share/qemu/ovmf-x86_64-ms-code.bin