miczyg1
commented
3 months ago @zirblazer Question: What is the purpose of linking the MS Project Olympus from OCP?
Prerequisites:
-
EEPROM size concerns - today's chips have 16 or even 32MB flashes. We have lots of space, especially if we will get rid of vboot. We could even go for 256K or 512K for UEFI NVARAM storage.
-
TPM interdependency - forget it, irrelevant. Measured boot simply hashes the certificates and records the measurements in the TPM PCRs and event log. There is no dependency, whatsoever.
-
Password protected Secure Boot Setup - we have setup password already. Once set you won't eneter setup without providing a correct one, then freedom inside.
Improvements
Secure Boot Modes, and UEFI Specification vs colloquial naming schemes
There is no such thing as Custom Mode, it is not even a mode of Secure Boot. It is just a switch to "God Mode" where you can freely modify keys and databases regardless of Secure Boot state (no need to do authenticated variable updates signed with private keys). I also don't see much value in making thing even more complex by adding Audit and Deployed mode to the pool of available states currently. A lot of work with nearly no benefit.
Custom Mode
Again, it is not Secure Boot mode. It just acts as a physical presence check to enter God Mode. It is volatile state just to give you free RW access to all keys. Can be treated as platform-specific way of resetting/removing PKpub
Vendor Keys
VendorKeys should default to 1, and be set to 0 if the user made at any point custom changes (Which essentially means moving out of Standard Mode
Again, incorrect understanding of what Standard Mode is. Standard Mode simpyl states that yo ucan only update the keys if you have a key database variable update signed by respective private key. The opposite of "God Mode" (Custom Mode), os basically the way how Secure Boot normally operates (e.g. how one can enroll/update Secure Boot key database having an old private key and a new private key).
browsing the Key Databases
It is GUID, not the same as UUID in the certificate. 8BE4DF61-93CA-11D2-AA0D-00E098032B8C is the GUID of the GlobalVariable as defined by the UEFI Spec. As the default keys are being enroll by the UEFI variable driver itself, thus they are given the GlobalVariable GUID. The Help section contains the certificate type as understood by UEFI Spec.
Far from ideal, but we already have a pending work for it: https://github.com/Dasharo/edk2/pull/149
Secure Boot MENU
Things like Query User for Option ROMs probably won't work. OptionROMs are attempted to be executed before the console is up (graphical or serial). You won't have a chance to query user what to do with an OptionROM, especially a VGA ROM. It is still valid for EFI Executables, because you typically execute shims or bootloaders when the console is already up.
EFI Executables Policy
Instead of having a global switch for all Executables, one could also pick a hash of EFI Executable (as for the EFI OptionROM) and enroll the hash to the allowed images to be executed. I saw something like that on HP laptops. You just select the file you wish to boot when Secure Boot is enabled and the hash is recorded (I hope it is a hash, not the file path... that would be stupid). I think it would be better than having something as shitty as MSI Insecure Boot-like options... i would do the same with EFI Option ROMs Policy, simply enroll the ROM hashes you need. VGAs will always be a problem, because because you are either secure or give bad UX if ROM is not signed.
Deleting/restoring databases
It is already there: https://docs.dasharo.com/dasharo-menu-docs/device-manager/#custom-mode-and-key-management
Secure Boot - Enabled / Disabled
Does it gets into effect on current session if saving Firmware settings and continuing to boot without reset, or requires a mandatory reboot to check EFI Option ROMs?
Of course all Secure Boot changes require a reset. otherwise it would be pointless.
Total size (Bytes) of Secure Boot Key Databases Available size (Bytes) in UEFI user NVRAM capacity Read only.
I don't think it is that important? Especially in the context of what I have wrote in the EEPROM size concerns answer
RANDOM UNSORTED INFO
DBR - more about OS recovery is explained in 3.4.1 OS-Defined Boot Option Recovery of UEFI Spec. DBR is used to update/authenticate OsRecovery#### variables. not implemented currently in EDK2
DEVDB - device authentication, explained in 32.7 Device Authentication in UEFI spec. Pretty much it is left to the developer how the policy will look like. Anyway, it is not about OptionROM validation, although it could be if the developer wants to put some info about OptionROM into the policy. However, this looks very much platform-specific, as you need to describe the devices per platform. It's very cool for high security, but I'm not sure how it should be implemented to make an actual benefit of it.
I have put it into markdown so it is formatted a little bit better: https://pad.3mdeb.com/code/#/2/code/edit/avUtJEX1NigTwyfhhjnf2pEM/
zirblazer
pietrushnic
mkopec
This is copypasted from a TXT that I wrote six months ago. Don't expect that I learn Markdown just to parse it here, heh.
These are the features that I expect from Secure Boot and the interfaces required to make it flexible and configurable enough for a variety of use cases.
This was written by looking at several sources:
...and others related to localized topics, mentioned where they're relevant.
So this is a mix of what the UEFI Specification mandates, how some currently available implementations behave, and what should be required to be at least on feature parity with them.
Prerequisites:
1 - Screen resolution size concerns
TianoCore has a built-in text-based configuration interface reminiscent of the late 90s/early 2000 BIOS Setups, which means that by 2023, it will be brutally lacking in polishing. While this is a long-term concern thus out of my current scope, any configuration interface that is going to display a lot of data, like the X.509 key certificates used for Secure Boot, will have to consider a layout that makes all the data shown on screen easy to understand for an average human user. To think about a design to present such data helpfully, the very first concern is screen resolution, which will limit which layouts are viable based on available screen real estate since you have to figure out if all the data fits on the screen, if you have to add multiple pages per entry, or if you instead want to truncate part of the data or not display all possible data fields. The resolution of the TianoCore interface may change based on the Monitor/Video Card negotiated screen resolution based on Monitor EDID. So far, these are possibly the most relevant resolutions:
On big resolutions, the vast majority of the TianoCore configuration interface screen is currently empty real state. It may be possible to use either a single one-size-fits-all layout aimed at 800 x 600 or perhaps have another, more detailed layout if you have a resolution that allows you to fully use it, like 1920 x 1080. If a more advanced GUI ever gets implemented, UI scaling could be useful (4K seems magnifier friendly to me, but with UI scaling it should be easy because 3840 x 2160 is exactly twice the 1920 x 1080, and 4096 x 2160 could be that plus two vertical black bars to the sides as to not require stretching).
It may also be worth considering if the interface should be viable for Serial Port Redirection, which, depending on settings, could be as small as an 80 x 24 character terminal. ASRock Rack Motherboards provides this feature to access Firmware from a Serial Port plugged to another computer. OVMF also supports it for VMs, which should be useful for development. Note that on the Dasharo-supported MSI boards, there is a sort of partial, unidirectional Serial Port that can output but not receive input, so Serial Port Redirection is not useful for these. (Perhaps you may replace a directly plugged Monitor with a Serial cable plugged to another computer, but it would still need a local Keyboard.)
2 - Flash EEPROM size concerns
Since UEFI Secure Boot key certificates, along with a lot of other things like UEFI Boot Entries and SMBIOS Error Logs (If they ever get implemented), are stored in the Motherboard Flash EEPROM where they also share space with the rest of the Motherboard Firmware, the actual available capacity for the UEFI user NVRAM is rather limited, and it means that it is not technically impossible to completely fill it by adding more certificates (I would point out at the DBX database as a possible threat, since the hashes blacklist keeps getting bigger and bigger). According to the UEFI Specification, in such a scenario, the Firmware can either return an error if trying to enroll a key certificate when the UEFI user NVRAM is full or automatically delete older certificates based on some criteria, which I personally consider dangerous and possible to exploit.
In the past, poor implementations of writing to UEFI user NVRAM could cause the computer to brick when it was close to full, which was the case of certain Samsung Notebooks, which were heavily featured in the news a decade ago.
While I would expect than nowadays there are more sanity checks to forbid this scenario to happen, UEFI user NVRAM capacity concerns are still a potential problem, even more so after UEFI Secure Boot, precisely because each certificate consumes a lot of precious space (Somewhere about 1-2 KiB per certificate).
So far, I haven't seen or even heard about any Firmware implementation that actually keeps track of how much of the UEFI user NVRAM is in use so that the user can plan ahead regarding capacity concerns. Some Firmwares like those of ASUS do display the size of the certificate databases, yet not the total or available user NVRAM:
3 - TPM interdependency
I'm aware that there can be some cooperation between UEFI Secure Boot and a TPM (Either a Firmware TPM or a discrete Hardware one) based on PCR 7 (Platform Configuration Register) values, but I only contemplate the use of Secure Boot in a standalone way.
My minimal understanding about this cooperation is that the TPM can validate that the Secure Boot Key Database has not been tampered with via external, non-authorized means, like, for example, flashing a Firmware image with a different Key Database to the Motherboard Firmware Flash EEPROM. However, in the case of a fTPM, the TPM user data is also part of the same UEFI user NVRAM, so technically, you are capable of modifying both the Key Database and the fTPM measurements simultaneously to make them match. I am not sure how hard it is to pull that off, nor if it kills the whole point of using TPM to audit Secure Boot if you don't have a discrete TPM (Average users use fTPM, albeit Dasharo users should be more likely to have dTPM based on target audience). I'l leave to someone else to provide suggestions about any possible usefulness of making both features cooperate or to just deal with them as entirely independent features.
4 - Password protected Secure Boot Setup
In all consumer and prosumer systems that I have seen, it is very easy to disable Secure Boot from within the Firmware interface along with doing other things like enrolling or deleting stored certificates. This flexibility is most likely because when Microsoft pushed for vendor Secure Boot support for Windows 8, its computer certification requeriments made mandatory than the Firmware must allow the user to disable Secure Boot (Not sure if there were further Secure Boot requeriments regarding customization). However, the UEFI Specification prefers to talk in more technical terms that doesn't seem to be directly correlated to how it is done in practice. For example, the UEFI Specification mentions that in order to delete the current PKpub (Platform Key), you need to provide the PKpriv to authorize this deletion. Since almost every DIY Motherboard or full computer sold comes with the PKpub already enrolled, it makes you believe that you would need to contact the vendor Firmware division to help you to clear the current PKpub, but this on practice doesn't happen because you can delete it from within the Firmware itself with no authorization required. The UEFI Specification does mention a possible "Platform Specific PKpub Clear" method, but otherwise I can only assume that either no one is following the UEFI Specification in this regard because Microsoft requeriments overruled it, or that it only focuses on the interactions between Firmware and OS in case you wanted to delete the PKpub from within an OS, while allowing anyone else with access to the Firmware interface to be essencially in "God Mode".
Since from within Firmware you can enroll and delete key certificates along with enabling or disabling Secure Boot with no restrictions, I would believe that changes to Secure Boot would require to provide an admin password, if configured (Or admin password to enter Firmware setup then full freedom once inside?). Is there any other layer of protection to add/delete Secure Boot certificates from within Firmware? Having to insert an USB Flash Drive with a PKpriv certificate or whatever else to authorize changes to Secure Boot seems to fit more the UEFI Specification wording than how it actually works in practice. Whatever method chosen, it should strike a balance between being secure and allowing you to reset the PKpub so that it doesn't become instant eWaste if the vendor doesn't want to provide you a means to clear its PKpub, or you lose your own custom PKpriv.
Current situation and proposals:
1 - Secure Boot Modes, and UEFI Specification vs colloquial naming schemes
The very first thing that I noticed is that is hard to map how TianoCore and most other vendors Secure Boot implementations work compared to what the UEFI Specification says. For example, when enabling Secure Boot, in most implementations you can set it to either Standard Mode or Custom Mode, whereas the UEFI Specification mentions Setup Mode (Which is actually available, but you don't "set" it in an explicit way, it is simply a consequence of deleting the PKpub via any means), Audit Mode, User Mode and Deployed Mode. According to the UEFI Specification, which mode the system is currently in is based on the presence of a PKpub and the values of the SetupMode, AuditMode, DeployedMode and SecureBoot variables plus their Read/Write or Read-only status, with the possible valid combination listed as follows:
Setup Mode PKpub = None SetupMode = 1 (RO) AuditMode = 0 (RW) DeployedMode = 0 (RO) SecureBoot = 0 Audit Mode PKpub = None SetupMode = 1 (RO) AuditMode = 1 (RO) DeployedMode = 0 (RO) SecureBoot = 0 User Mode PKpub = Enrolled SetupMode = 0 (RO) AuditMode = 0 (RW) DeployedMode = 0 (RW) Deployed Mode PKpub = Enrolled SetupMode = 0 (RO) AuditMode = 0 (RO) DeployedMode = 1 (RO)
As such, the first question is whenever you want to be as close as possible to what the UEFI Specification says and use its naming scheme, or stick to what is already colloquial and expected. So far, Custom Mode should be User Mode and Standard Mode should be Deployed Mode, with Audit Mode having no direct counterpart. I have no idea if current TianoCore implementation matches UEFI Specification and can display which Mode the system is currently in based on the presence of the previously mentioned variables.
From the vendors, Supermicro has a document, Secure Boot Configuration Instructions for The X12 Motherboards, explaining the basis of their Secure Boot implementation: https://www.supermicro.com/manuals/other/X12_Secure_Boot_Guide.pdf It seems to rely on switching between Standard Mode and Custom Mode just like TianoCore, but also making direct mentions to Audit Mode and Setup Mode. However, it doesn't mention how Audit Mode is supposed to work. Dell in its PowerEdge C6525 Firmware seems to explicitly use all four Secure Boot Modes, and also has a ruleset to switch between them that seems to match UEFI Specification expectations: https://www.dell.com/support/manuals/en-us/poweredge-c6525/pecc6525_bios_ism_pub/system-security?guid=guid-65a67b2f-d457-4d8b-bf20-a24875cc54b5 Audit Mode is interesing because it seems to be equivalent to booting with Secure Boot disabled but populating the Image Execution Information Table with all the EFI images that were executed.
2 - Custom Mode reverts to Standard Mode, and can't browse Key Databases without switching to Custom Mode
In TianoCore, you can set Secure Boot to either Standard Mode or Custom Mode. The common sense assumption is that Standard Mode uses the factory enrolled Microsoft certificates already in the Firmware image, which it does. Setting it to Custom Mode makes the interface to show a previously not visible Key Database menu, where you can view the preenrolled keys. However, upon exiting this menu and entering Secure Boot menu again, even if you made changes like deleting a key, it appears as if it has reverted back to Standard Mode, making you believe than no changes were made even though if you set it back to Custom Mode, you can see any changes you made in the Key Database. This behavior is completely misleading. Besides than this makes the Mode change meaningless, the Key Database menu should be always visible even in a read-only mode as a means to audit the currently enrolled keys.
3 - Proper usage of the VendorKeys variable
A particular question that arises from the previous point is, how do you know if the Key Databases were modified if you are effectively always running in Standard Mode? Moreover, the contents of the Key Databases themselves are not fixed because while the preenrolled keys of the Firmware image are known, these can change at runtime based on OS-side updates, like when Windows Update pushes a DBX Key Database update, so Standard Mode key contents are not an inmutable factory default on the first place. Thus the concept of the Key Databases having been tampered is pretty much about direct user intervention. The UEFI Specification mentions a variable, VendorKeys, that is supposed to monitor whenever Secure Boot Policy Variables (One of which are the contents of the Key Databases) were at some point changed by a non-key holder. A non-key holder would essencially be an user from within the Firmware in "God Mode", which can enroll and delete keys at will, whereas a key holder would be Microsoft thanks to the preenrolled KEKpub key. VendorKeys should default to 1, and be set to 0 if the user made at any point custom changes (Which essencially means moving out of Standard Mode. User should be warned than this changes VendorKeys to 0 permanently). It should also be possible to reset VendorKeys back to 1 if cleaning all current keys and enrolling again the Firmware default ones. This value should be visible, too.
4 - Rework how browsing the Key Databases works and the data from certificates that is displayed
TianoCore Key Management menu allows you to view enrolled certificates from the Secure Boot Key Databases, namely PK, KEK, DB, DBX and the later defined DBT. For unknown reasons, it shows each certificate entry as a generic UUID, 8BE4DF61-93CA-11D2-AA0D-00E098032B8C with no other basic details given about the certificate itself, like its name, usually found as CN (Common Name). Moreover, the UUID could be repeated in multiple entries, so for example, in Dasharo for MSI you can have in DB database 4 entries with the same UUID being displayed and no information whatsover about what the certificates actually are. This means that attemping to manage certificates from within the Firmware interface is borderline useless as you're basically deleting things blind. Additionally, attemping to enroll a certificate ask for an UUID value, which becomes the entry name on the database list. This value can be all zeroes if the user desires. I have no idea if the UUID is mandatory or just TianoCore way of internally identifying them, but the UUID itself doesn't seem to be part of the original certificates data structure themselves, so why not use data from it instead? At MINIMUM, the displayed UUID should be replaced with the Common Name of the certificate (For example, Microsoft Windows Production CA 2011, but I don't know which specific field of the X.509 specification CN uses) so that they can be identified from within Firmware for any other operation, like deleting or backuping them. Being able to have a detailed view of an entry (Like in a popup menu) to get additional information about the certificate of any other useful fields would be even better. Since certificates are data heavy, how much information is convenient to display will depend on screen real estate as mentioned elsewhere. Note that there can be both X.509 certificates and almost bare hashes on the same databases, and I'm not sure if these hash entries can have their own description.
5 - MOK and MOKX Key Databases contents should be visible in Firmware
The shim Boot Loader used by Linux distributions supporting Secure Boot introduces the MOK and MOKX Key Databases. While not part of the UEFI Specification, their behavior seems to be similar or identical to standard Secure Boot certificates, and they are also stored in the UEFI user NVRAM. At the moment, there is no way from within the Firmware itself to visualize or interact with the MOK or MOKX Key Databases, you have to do it from within an OS, which leaves a major blind spot, as you can reset all keys and still have MOK and MOKX certificates enrolled. Thus, while not part of Secure Boot itself, it does make sense to put them as a Key Management submenu.
6 - Review and document File Formats for importing/enrolling certificates and exporting/backuping them
Certificates and hashes can be stored in a multitude of different file extensions and encodings, with the available Linux and Windows userspace toolchains favouring different defaults. Since it is easy to convert them from one format to another this poses no real problem, but it may still be cumbersome to deal with. It should be useful to properly document what are the minimum formats than the UEFI Specification ask for, what TianoCore currently supports, which userspace toolchains in both Linux and Windows can deal with those formats, and whenever supporting to directly be able to import and enroll any alternative format is worth consideration. Likewise, this also happens when exporting certificates currently stored in the UEFI NVRAM. So far, most Firmwares allows you to backup them from within the Firmware interface itself, but it faces certain limitations that could be improved. For example, you can export the contents of an entire Key Database like all of DB, but it doesn't allows you to choose an individual certificate to export, which means that you have to use userspace tools to extract an individual certificate from the bulk database export. You also can't backup all databases for convenience at once, nor choose which file format will be used for exporting. Some Firmwares may also allows you to export only to removable devices and not the ESP or any other Partition with a supported File System from a fixed disk drive. The NSA UEFI Secure Boot Customization document on Chapter 4 has very detailed procedures on how to backup current certificates from either an OS (Linux or Windows) or from within the Firmware interface itself using as example the Firmware of a Dell OptiPlex 7050 (Slide 16 / Page 10), along with enrollment (Slides 26-27 / Page 20-21), and using userspace tools to convert between formats.
7 - Make possible to capture hashes of PCI Option ROMs from within Firmware
While customizing Secure Boot for anything that involves EFI images in file format like UEFI Boot Loaders or Linux Kernels is within the realm of the possible for regular mortals, for EFI images in PCI Option ROMs it is the exact opposite. Validating these Option ROMs is entirely reliant on the Secure Boot ecosystem that Microsoft built though its third party certificate, so deleting it means that by default, on a strict Secure Boot system that refuses to load anything not signed, no add in PCIe Card would work (This situation is equivalent to the Microsoft Secured-core PCs that doesn't use by default the Microsoft third party certificate). Even worse, depending on implementation, just having such card installed could make the system to stop at POST. Dumping an Option ROM, signing it and flashing it back to the PCIe Card, while technically possible, is just too complicated for users and thus not a good solution, plus it may cause issues with any other kind of validation of the Option ROM by the card vendor, like in its Drivers. The NSA UEFI Secure Boot Customization document on Chapter 4.3.3 (Slide 23 / Page 17) shows the Firmware of a Dell PowerEdge R740 being able to export the hashes of certain PCI Devices, which I assume that are those with an UEFI image in their Option ROMs. Since in order to capture the hashes of any installed card it obviously has to be done at runtime, it should be possible for an user to complete POST of the system in a kind of Audit Mode (Or equivalent) that disallows the user to boot if Secure Boot is enabled, but shows a list of UEFI images from PCI Devices detected and ask the user whenever to enroll their current hashes, with perhaps more information like the PCI ID/Device ID and maybe PCI Address from where the hash was captured. This means that at least it should be possible to notice alterations to an Option ROM (Or enroll a new hash if there is a vendor provided Option ROM update). Note that this would still be equivalent to soft bricking for users of systems that have no Processor/platform integrated graphics with built-in signed UEFI GOP in the Firmware, since having Secure Boot enabled means that no discrete Video Card would work before enrolling, and good luck doing so if it is the only Video Card available in the system. The UEFI Specification has something about that in 32.4.2 Image Execution Information Table regarding how Audit Mode is supposed to be used that could be related to this. Also note than the UEFI Specification mentions a DEVDB database intended for Devices, but there isn't a lot of info about use cases nor what you can accomplish with it that can't be done by putting PCI Option ROM certificates and hashes on the standard DB database.
8 - Potential to make Secure Boot less strict with Option ROMs
TianoCore implements something called the Secure Boot Policy, which is best described as what would be Secure Boot behavior in the case than the signature check of an Option ROM UEFI image or of an EFI executable fails due to it not being present on the DB Database (Or being blacklisted by DBX). Though it went against the UEFI Specification itself, TianoCore originally provided a means to configure this policy in a way that allowed it to skip validating either or both of the Option ROMs and EFI executable signatures, up to the point that it would do absolutely no validation at all yet still report to the user and the OS that Secure Boot was enabled. Such options and their descriptions can be viewed in the 2017 Open Compute Project Project Olympus BIOS Specification at 11.2.3 Secure Boot Policy: https://www.opencompute.org/documents/microsoft-project-olympus-intelr-xeonr-scalable-processor-bios-specification This was supposedly deprecated by TianoCore a long time ago, yet multiple vendors Firmwares still implement these options as of 2024. Recently, there was a case where a Motherboard vendor, MSI, decided to ship Firmware updates with these validation skips (Always Execute) enabled by default, making Secure Boot being enabled effectively meaningless because it stopped on nothing. This achieved media coverage when an user reported it: Dawid Potocki Blog - MSI's (in)Secure Boot - https://dawidpotocki.com/en/2023/01/13/msi-insecure-boot/ Dawid Potocki Blog - MSI's (in)Secure Boot: Part 2 - https://dawidpotocki.com/en/2023/02/26/msi-insecure-boot-part-2/ While a rather controversial point, there may be some reason in this madness. Your average user that knowns nothing about how Secure Boot works beyond checking for its status (Either disabled, or enabled with default Microsoft certificates) may still known how to install older PCIe cards whose Option ROMs aren't signed, or how to flash Video Cards with custom modded Option ROMs to overclock them, which obviously cause them to lose their valid signatures. Installing such cards on a system with the expected strict Secure Boot policy would result in it not POSTing and a dissapointed user making a support requests, which is a problem if the vendor Firmware that you're trying to replace simply work out of the box due to them being factory configured to skip the validation of Option ROMs. Note than this is actually considered an issue by Microsoft in its UEFI Validation Option ROM Guidance at 2. Problem statement: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/uefi-validation-option-rom-validation-guidance?view=windows-10#2-problem-statement The proper way when dealing with such scenarios would be to simply disabling Secure Boot, but this would cause certain Software to refuse to work, like the Windows 11 installer, which wants Secure Boot to be enabled, or an increasing amount of games whose anti cheats that also demands for Secure Boot to be enabled. Thus, for compatibility reasons, being able to report Secure Boot being enabled and not actually enforcing it may not be such a bad idea. Also note than in the case of MSI, the issue was noticed because it was skipping checking EFI executables (Boot Loaders) signatures in addition to Option ROMs. I don't know how widespread defaulting to skipping Option ROM validation is because people tends to complain when things don't work instead of when they work (Even if they may not be supposed to, but the user doesn't knowns or don't care about this). Additionally and only partially related, the NSA document also mentions than several options found in vendor Firmwares like Fast Boot (Which skips loading Option ROMs) can make them to skip checking for signatures in these Option ROMs even when Secure Boot is enabled, which is similar, but not identical, to this issue.
Secure Boot MENU
Should Secure Boot Key Database be factory provisioned so that the default status after flashing Dasharo includes the certificates already enrolled (Whenever Secure Boot defaults to enabled or disabled), or should it be empty, and ask the user to restore factory certificates before Secure Boot can be enabled if trying to enable it with nothing enrolled? For Option ROM testing purposes, Microsoft UEFI Validation Option ROM Guidance document actually suggest enabling Secure Boot with enrolled PK and KEK but empty (NULL) DB and DBX, so doing that should be possible
Current Secure Boot Status Enabled / Disabled Read Only. Self explanatory Current Secure Boot Mode Setup Mode / Audit Mode / User Mode / Deployed Mode Read Only. This pretty much depends on whenever you want to stay with the colloquial Standard Mode and Custom Mode definitions or not You can also provide individual visibility to the SetupMode, AuditMode and DeployedMode variables It may be possible to consolidate Current Secure Boot Status and Current Secure Boot Mode onto the same display, since it is either Disabled or a Mode Key Database Tampering Factory Defaults / Modified by direct user intervention Read Only. Pretty much a common sense name for the VendorKeys variable The default is 1, permanently set to 0 if the Key Database has been tampered with from within Firmware itself until next default certification reset
Secure Boot Enabled / Disabled Self explanatory. Does it gets into effect on current session if saving Firmware settings and continuing to boot without reset, or requires a mandatory reboot to check EFI Option ROMs? Secure Boot Mode Setup Mode / Audit Mode / User Mode / Deployed Mode This is where most Firmwares allows you to choose Standard Mode or Custom Mode Does setting Secure Boot Mode as an explicit option makes sense? Setup Mode and Audit Mode depends on clearing the PKpub. How should this be deal with? Changing the Secure Boot Mode from Deployed Mode to anything else (Perhaps except User Mode, assuming it checks for authorization when enrolling) should also set VendorKeys variable to 0
EFI Option ROMs Policy Always Execute / Always Deny / Allow Execute / Defer Execute / Deny Execute / Query User On a strict Secure Boot system, anything not on the DB Database should never be executed. However, for certain type of users validating Option ROMs could be considered overkill It is not unusual to do things like modding an Option ROM that would invalidate its signing, but you may still want for Secure Boot to be enabled to validate Boot Loaders or other kind of OS side requeriments Is there any relationship between this and Audit Mode? Perhaps available for User Mode, not configurable in Deployed Mode EFI Executables Policy Always Execute / Always Deny / Allow Execute / Defer Execute / Deny Execute / Query User On a strict Secure Boot system, anything not on the DB Database should never be executed. Validating EFI Executables like Boot Loaders is the very minimum that I'm expecting Secure Boot to do to justify some kind of usefulness This option pretty much allows to bypass main Secure Boot function, completely invalidating its purpose thus making it very dangerous for production environments. It is the source of the MSI Insecure Boot saga Since it allows to skip the Secure Boot validation checks but still reports to the OS that Secure Boot is enabled, it may still be useful for compatibility or research purposes
View Image Execution Information Table (Audit Mode) UEFI Specification mentions in 32.4.2 the Image Execution Information Table that should be used for Audit Mode, but I didn't found examples of how it is implemented In theory, it should show all UEFI images that were loaded. Not sure how it would help in the case of Boot Loaders, that are pretty much executed at the end of the Firmware stage Could be redundant with the "Capture hash of an EFI Option ROM" and "Capture hash of an EFI Executable" below After some reading, it seems to be intended to be read OS side, so in Firmware it could be partially available to see Option ROMs, but will not be populated by EFI executables like Boot Loaders after Firmware stage finishes
Restore Secure Boot Factory Defaults databases and variables (Reverts to Deployed Mode) Should delete everything on the UEFI user NVRAM that relates to Secure Boot, then inmediately enroll the Firmware default PK, KEK, DB and DBX certificates in Deployed Mode. Also resets VendorKeys variable back to 1 Delete ALL Secure Boot databases and variables (Reverts to Setup Mode) Quick way to completely obliterate anything on the UEFI user NVRAM that relates to Secure Boot. Should be considered a shortcut for customizing from scratch
Key Management MENU It should be possible to access this menu in a read-only mode where you can browse the currently enrolled keys and can export them, but not import, without switching from Deployed Mode (Or Standard Mode) first
Total size (Bytes) of Secure Boot Key Databases Read only. Self explanatory Available size (Bytes) in UEFI user NVRAM capacity Read only. Self explanatory. Is this capacity dynamically shared along all other NVRAM usages or it is partitioned thus exclusive for Secure Boot Key Database?
Capture hash of an EFI Option ROM Should be either a submenu or a popup window, that shows a list of detected Option ROMs with PCI Address, PCI Vendor ID and PCI Device ID After selecting a PCI Device, it should allow to either save the EFI Option ROM hash to a file in a removable or fixed drive, and if the current Secure Boot Mode allows, to directly enroll it to the DB (Or DEVDB?) Database If the certificate format allows, it could be useful to save in the file or UEFI user NVRAM entry data about the PCI Device than this was captured from and use it as default display name Capture hash of an EFI Executable Should be either a submenu or a popup window, that shows a list of detected ESPs on fixed drives. Not sure if removable drives should be included by default After selecting an ESP, it should open a file explorer that allows to select an EFI Executable and save the hash to a file in a removable or fixed drive, and if the current Secure Boot Mode allows, to directly enroll it to the DB Database If the certificate format allows, it could be useful to save in the file or UEFI user NVRAM entry data about which file this was captured from and use it as default display name
All of the supported Key Databases should bave its own submenu UEFI Secure Boot standard KEK, DB, DBX, plus Linux Shim MOK and MOKX submenues should share interface. I have no idea about how DBT certificates works and if they can share it, too PK submenu interface may be slighty different due to it only supporting a single certificate Is unknown whenever DBR and DEVDB are implemented, nor I'm sure about how these are supposed to work
Key Database types
PK Platform Key Only one PK can be enrolled KEK Key Exchange Key Signature Database DB Signature Store EFI_IMAGE_SECURITY_DATABASE DBX Blacklist Signature Store EFI_IMAGE_SECURITY_DATABASE1 DBT Timestamp Signature Store EFI_IMAGE_SECURITY_DATABASE2 DBR OS Recovery Signature Store EFI_IMAGE_SECURITY_DATABASE3 No idea if TianoCore implements it nor how it is supposed to be used DEVDB Device Authentication Signature Database EFI_DEVICE_SECURITY_DATABASE No idea if TianoCore implements it nor how it is supposed to be used MOK Machine Owner Key Linux Shim, not on UEFI Specification MOKX MOK Exclusion Linux Shim, not on UEFI Specification
Common default Secure Boot certificates
KEK Microsoft Corporation KEK CA 2011 https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt KEK Microsoft Corporation KEK 2K CA 2023 https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt DB Microsoft Windows Production CA 2011 (Windows OS Loader) https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt DB Windows UEFI CA 2023 (Windows OS Loader) https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt DB Microsoft Corporation UEFI CA 2011 (Third Party) https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt DB Microsoft UEFI CA 2023 (Third Party) https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt DBX UEFI Revocation List File for x64 (64 bit) https://uefi.org/revocationlistfile
Possible Certificate File Formats
.esl (EFI Signature List) .auth (Signed EFI Signature List) .crt (PEM) or .pem .cer (DER) or .der .hash or .hsh
Variables mentioned by the UEFI Specification
SecureBoot 3.3. Globally Defined Variables Slide 167 / Page 83 SetupMode 3.3. Globally Defined Variables Slide 166 / Page 82 AuditMode 3.3. Globally Defined Variables Slide 167 / Page 83 DeployedMode 3.3. Globally Defined Variables Slide 167 / Page 83 VendorKeys 3.3. Globally Defined Variables Slide 167 / Page 83 devAuthBoot 3.3. Globally Defined Variables Slide 167 / Page 83 and Slide 168 / Page 84 PKDefault 3.3. Globally Defined Variables Slide 167 / Page 83 KEKDefault 3.3. Globally Defined Variables Slide 167 / Page 83 dbDefault 3.3. Globally Defined Variables Slide 167 / Page 83 dbxDefault 3.3. Globally Defined Variables Slide 167 / Page 83 dbtDefault 3.3. Globally Defined Variables Slide 167 / Page 83 dbrDefault 3.3. Globally Defined Variables Slide 167 / Page 83 devdbDefault 3.3. Globally Defined Variables Slide 168 / Page 84
Miscellaneous links: