Im UEFI lässt sich SecureBoot aktivieren/deaktivieren. Oft ist parallel dazu auch die Konfiguration von TPM(TrustedPlattformModul) möglich.

Auf Rechnern mit UEFI und ohne aktivierter rückwärts-Kompatibilität zum alten BIOS Standard können nur Datenträger mit Betriebssystemen gestartet werden, welche eine entsprechende Boot Partition haben.

Hier ist die Boot Partition die 1. Partition auf dem Datenträger /dev/sda, also unter Linux mit /dev/sda1 angesprochen.

iglu:~ # parted -l
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 53.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   51.5GB  51.0GB  btrfs
 3      51.5GB  53.7GB  2149MB  linux-swap(v1)        swap

Die Partitionstabelle muss gpt sein, das Dateisystem FAT und bei Flags muss boot, esp stehen.

Zu beachten ist, das auf einem PC mit mehreren Betriebssystemen es dazu kommen kann das ein System nicht mehr bootet mit der Meldung „Security Validation Failed“.

Fehlermeldungen die auftreten können:

ERROR verification failed 0x1A security violation

Failed to load image: Security Policy Violation

Failed to open \EFI\BOOT\mmx64.efi Not Found

error:shim_lock protocol not found

bad signature: (hd0, ecx4) /database2/boot/kernel_mapping)

Eine Abhilfe bietet hier das mokutil.

Es ist evtl. nötig die default Keys im UEFI wieder herszustellen, der Secure BootStick verlangt evtl. den Standard Microsoft Key

Folgende Kommandos zeigen zumindest:

mokutil --kek

• [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Platform Key
• [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root

mokutil --db

• [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Key Exchange Key
• [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
• [key 3] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010

mokutil --dbx

• [key 1] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
• [key 2] = [SHA-256] 80b4d96931b… ewig lang …856967df8e

Ansonsten gilt: Secure Boot deaktivieren und die folgenden Kommandos ausführen. Falls sich Secure Boot nicht deaktivieren lässt (Dell), dann ein System starten, welches mit den Standard Signaturen starten kann. In meinem Fall hatte OpenSuse neuere Keys bzw. seine eigenen Suse Key im NVRAM des UEFI Chips geladen und wohl auch die Secure Boot Advanced Targeting (SBAT) aktualisiert so das ältere Micosoft Keys nicht mehr funktionieren, sondern nur neuere Versionen davon - Hauptgrund warum der Boot-Stick nicht mehr startet.

folgender Kommando zeigt nur einen [key 1] Issuer: CN=SUSE Linux Enterprise Secure Boot CA - so sieht es auch aus wenn es funktioniert.

mokutil --list-enrolled

Disabling/re-enabling Secure Boot:

mokutil --disable-validation or mokutil --enable-validation
mokutil --reset
mokutil --set-sbat-policy previous / delete

Choose a password between 8 and 16 characters long. Enter the same password to confirm it. Reboot. When prompted, press a key to perform MOK management. Select „Change Secure Boot state“. Enter each requested character of your chosen password to confirm the change. Note that you have to press Return/Enter after each character.

- Select „Yes“. - Select „Reboot“.

Im MOK Manager der direkt nach dem reboot aufgerufen wird alles löschen bzw. deaktiveren, MOK List delete und Validation deaktiveren.

Wenn es funktioniert, dann sollte folgendes angezeigt werden:

mokutil --list-sbat-revocations

sbat,1,2022052400
grub,2

Manipulate the MOK blacklist

mokutil --mokx

Wird nach GRUB aufgerufen wenn festgstellt wird das Standard Bootloader nicht signiert ist Der shim Bootloader benötigt eine UEFI kompatible GPT Boot Partition sonst kommt die Meldung

# shim-install 
No valid EFI partition

The default boot loader used by openSUSE on UEFI systems is grub2. When in secure boot mode, an additional boot loader called 'shim' is used too. Instead of directly calling grub2 in that mode the firmware first loads 'shim'. 'shim' carries a signature by Microsoft in order to be recognized by the firmware. 'shim' in turn knows about the openSUSE certificate that was used to sign grub2. grub2 then is able to load linux kernels that are also signed by the openSUSE certificates. After loading the Linux kernel the scope of secure boot ends. The linux kernel used in openSUSE does not impose additional restrictions.

In order to allow having custom boot loaders as well as custom kernels shim offers a way to import custom signatures. The program 'MokManager' is used for that purpose. When 'shim' is instructed to load a binary that is not signed by a well known entity it calls into MokManager which allows to import certificates into the database of well known signature issuers.

Damit beim Suse Updates kein zu neuer restiktiver shim aktiv wird wurden nun sicherheitshalber Updates für shim blockiert:

iglu:~ # zypper la shim
Specified lock has been successfully added.

iglu:~ # zypper ll

# | Name | Type    | Repository | Comment
--+------+---------+------------+--------
1 | shim | package | (any)      | 

apt list "uefi"
Auflistung… Fertig
...
uefitool-cli/stable 0.28.0-1 arm64
uefitool-cli/stable 0.28.0-1 armhf
uefitool/stable 0.28.0-1 arm64
uefitool/stable 0.28.0-1 armhf

~ # efiboot

efibootdump  efibootmgr

Canonical EFI binary signing tools

sbsigntools

Boot funktioniert mit ECOS Stick

UEFI Einstellung:

TPM = deaktiviert

Secure Boot = aktiviert aber auf alles erlauben gesetzt. Schlüssel stehen auf Custom Mode enabled, d.h. man kann Schlüssel setzen und die Einstellungen bleiben, evtl. hier sogar keinen Custom Mode damit immer der Ursprung fest eingestellt bleibt? Z.B. bei Suse Updates.

systemd-boot not installed in ESP.
System:
     Firmware: n/a (n/a)
  Secure Boot: disabled
   Setup Mode: setup
 TPM2 Support: no
 Boot into FW: supported

mokutil --list-sbat-revocations

sbat,1,2022052400
grub,2

mokutil --sb-state
 
SecureBoot disabled   <-- sagt disabled im UEFI steht enabled
Platform is in Setup Mode

Erstaunlich, Kommandos liefern nichts zurück, kein Plattform Key? Im UEFI nur dbx gelöscht.

mokutil --pk

Dieser Kommando liefert nun 2 key zurück, in Suse keine Updates eingespielt, kann nur vom BootStick sein.

mokutil --dbx

Kommando mit –list-enrolled liefert wie zu erwarten den SUSE Key zurück

  mokutil --list-enrolled
  
  [key 1]
  ...
  Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Validity
            Not Before: Apr 18 14:33:41 2013 GMT
            Not After : Mar 14 14:33:41 2035 GMT
        Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de

Kommando efi-readvar liefert:

Variable PK has no entries
Variable dbx has no entries
Variable MokList has no entries

bei KEK: wird was angezeigt List 0 und List1 bei db: wird was angezeigt List 0, List 1 und List 2

Auslesen von dbx und speichern in Datei dbx.esl ?

efi-readvar -v dbx -o dbx.esl

Kommando efibootmgr -v zeigt natürlich bei meiner angesteckten USB Festplatte und gestarteten SUSE meine Suse Start Partition ganz oben. Wenn meine Festplatte weg ist, würde der folgende Eintrag starten:

Boot0004* RH2   PciRoot(0x0)/Pci(0x15,0x0)/USB(2,0)/HD(1,GPT,b90c1753-d520-47c9-a136-5a0ad43e2cd2,0x1000,0x5000)/File(\EFI\BOOT\BOOTx64.EFI)

fwupdmgr get-history
No history

Zeigt eine Liste der verbauten / angeschlossenen Geräte mit Update Informationen. Liste habe ich bereits gespeichert.

fwupdmgr get-devices

tux@iglu:/Downloads # keytool -printcert -file microsoft-uefica-public.cer 
Owner: CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US
Issuer: CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US
Serial number: 6108d3c4000000000004
Valid from: Mon Jun 27 23:22:45 CEST 2011 until: Sat Jun 27 23:32:45 CEST 2026
Certificate fingerprints:
         SHA1: 46:DE:F6:3B:5C:E6:1C:F8:BA:0D:E2:E6:63:9C:10:19:D0:ED:14:F3
         SHA256: 48:E9:9B:99:1F:57:FC:52:F7:61:49:59:9B:FF:0A:58:C4:71:54:22:9B:9F:8D:60:3A:C4:0D:35:00:24:85:07
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

#1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false
0000: 1E 0A 00 53 00 75 00 62   00 43 00 41              ...S.u.b.C.A


#2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 03 01 00 01                                     .....


#3: ObjectId: 1.3.6.1.4.1.311.21.2 Criticality=false
0000: 04 14 F8 C1 6B B7 7F 77   53 4A F3 25 37 1D 4E A1  ....k..wSJ.%7.N.
0010: 26 7B 0F 20 70 80                                  &.. p.


#4: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: caIssuers
   accessLocation: URIName: http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
]
]

#5: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 45 66 52 43 E1 7E 58 11   BF D6 4E 9E 23 55 08 3B  EfRC..X...N.#U.;
0010: 3A 22 6A A8                                        :"j.
]
]

#6: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#7: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName: http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl]
]]

#8: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

#9: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 13 AD BF 43 09 BD 82 70   9C 8C D5 4F 31 6E D5 22  ...C...p...O1n."
0010: 98 8A 1B D4                                        ....
]
]