You are not logged in.
This is the output of
# dmidecode -t bios
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: LENOVO
Version: H3CN46WW(V3.04)
Release Date: 01/12/2024
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.46
Firmware Revision: 1.46
Handle 0x0021, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Longs
Installable Languages: 4
en|US|iso8859-1
fr|FR|iso8859-1
ja|JP|unicode
zh|TW|unicode
Currently Installed Language: en|US|iso8859-1
So, after knowing that my laptop uses Lenovo's UEFI firmware. I read into the wiki and found this (the note in red). Now, I am wondering if my laptop also uses Lenovo CA certificate to sign its UEFI firmware and applications. And, if that is the case what can do to enable secure boot in that case?
MORE INFORMATION-
1. I am dual-booting with windows. So, I'll also be following this.
2. I seem to not have a problem with optionRom files as they are not a part of my bootchain. Read this for more info.
Now, I wanted to figure out a way to know it my UEFI firmware is signed by Lenovo CA certificate or not, and if it is not then validate it. This is all I could find-
$ efi-readvar -v db
Variable db, length 3969
db: List 0, type X509
Signature 0, size 1515, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
Subject:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
Issuer:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
db: List 1, type X509
Signature 0, size 1572, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
Subject:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
Issuer:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
db: List 2, type X509
Signature 0, size 798, owner e04fd794-033e-46a0-81d2-048e8da1432e
Subject:
CN=OK Certificate
Issuer:
CN=OK Certificate
Now, I know "77fa9abd-0359-4d32-bd60-28f4e78f784b" is Microsoft's GUID, but there's another GUID present "e04fd794-033e-46a0-81d2-048e8da1432e". Is this GUID associated with Lenovo? And if it is, will it interfere in the process of enabling secure boot? And, if it "does" interfere how do we solve it?
Last edited by chared (Today 18:07:03)
Offline
If you don't have any OpROMs then it should be safe to remove the manufacturer keys and replace them with your own. Keeping the Microsoft keys and adding your own removes any risk completely so you could do that instead if you're worried. UEFI firmware implementations tend to be very buggy so it's hard to give guarantees.
Last edited by Head_on_a_Stick (Yesterday 07:00:48)
Para todos todo, para nosotros nada
Offline
UEFI firmware implementations tend to be very buggy so it's hard to give guarantees.
Yeah, that's exactly my worry. If something goes wrong, I am pretty much screwed. This wouldn't have been a problem if I could find resources that refer to this same problem.
Offline
If you are worried about it you could pull out your EFI variables as outlined on this part of the wiki: https://wiki.archlinux.org/title/Unifie … _variables. I would do further research into how to restore the variables as well, I know sbctl can enroll keys, so looking at their mechanism for doing that might help as well.
Offline
Update: Everything went well, I just followed the sbctl part on the arch wiki but I also had to enroll my vendor keys with the --firmware-builtin (-f) flag. Again, I don't know if adding this flag does anything, but I wanted to be on the safer side of things.
Offline