Artix Linux Forum

Hello i'm doing the ultimate necroposting, you can do secure boot through sbctl as stated in the archwiki, make sure to run

Code: [Select]

sudo grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB --modules="tpm" --disable-shim-lock

and

Code: [Select]

sudo grub-mkconfig -o /boot/grub/grub.cfg

or else it will fail to boot

also when you verify, vmlinuz-linux may not show up, so u gotta sign it manually:

Code: [Select]

sudo sbctl sign -s /boot/vmlinuz-linux

       enroll-keys
           Enrolls the created key into the EFI variables.

               Note that some devices have hardware firmware that is signed and
               validated when Secure Boot is enabled. Failing to validate this firmware
               could brick devices. It's recommended to enroll your own keys with
               Microsoft certificates.

           -m, --microsoft
               Enroll UEFI vendor certificates from Microsoft into the signature database.

you don't need to sign the linux kernel with windows key. the UEFI can accept multiple certs in the database. so when initializing The UEFI secure boot, you create your own keys and certs and also include microsoft certs. then, you sign the kernel with your own key. UEFI will pass if any of the cert match the sign of  file.

Quote

       enroll-keys
           Enrolls the created key into the EFI variables.

               Note that some devices have hardware firmware that is signed and
               validated when Secure Boot is enabled. Failing to validate this firmware
               could brick devices. It's recommended to enroll your own keys with
               Microsoft certificates.

           -m, --microsoft
               Enroll UEFI vendor certificates from Microsoft into the signature database.

I'm confused.  As I read the UEFI standard there is ONE platform key and it is inserted by the hardware vendor (which makes is MS key).

This section describes a means of creating a trust relationship between the platform owner, the platform firmware, and an operating system. This trust relationship enables the platform firmware and one or more operating systems to exchange information in a secure manner. The trust relationship uses two types of asymmetric key pairs:

Platform Key (PK)
The platform key establishes a trust relationship between the platform owner and the platform firmware. The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key. See “Enrolling The Platform Key” and “Clearing The Platform Key” for more information.

Key Exchange Key (KEK)
Key exchange keys establish a trust relationship between the operating system and the platform firmware. Each operating system (and potentially, each 3rd party application which need to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware. See “Enrolling Key Exchange Keys” for more information.

While no Platform Key is enrolled, the SetupMode variable shall be equal to 1. While SetupMode == 1, the platform firmware shall not require authentication in order to modify the Platform Key, Key Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security databases.

After the Platform Key is enrolled, the SetupMode variable shall be equal to 0. While SetupMode == 0, the platform firmware shall require authentication in order to modify the Platform Key, Key Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security databases.

While no Platform Key is enrolled, and while the variable AuditMode == 0, the platform is said to be operating in setup mode.

After the Platform Key is enrolled, and while the variable AuditMode == 0, the platform is operating in user mode. The platform will continue to operate in user mode until the Platform Key is cleared, or the system is transitioned to either Audit or Deployed Modes. See “Clearing The Platform Key,” “Transitioning to Audit Mode,” and “Transitioning to Deployed Mode” for more information.

Audit Mode enables programmatic discovery of signature list combinations that successfully authenticate installed EFI images without the risk of rendering a system unbootable. Chosen signature lists configurations can be tested to ensure the system will continue to boot after the system is transitioned out of Audit Mode. Details on how to transition to Audit Mode are detailed below in the section “Transitioning to Audit Mode.” After transitioning to Audit Mode, signature enforcement is disabled such that all images are initialized and enhanced Image Execution Information Table (IEIT) logging is performed including recursive validation for multi-signed images.

Deployed Mode is the most secure mode. For details on transitioning to Deployed Mode see the section “Transitioning to Deployed Mode” below. By design, both User Mode and Audit Mode support unauthenticated transitions to Deployed Mode. However, to move from Deployed Mode to any other mode requires a secure platform-specific method, or deleting the PK, which is authenticated.

Secure Boot Mode transitions to User Mode or Deployed Mode shall take effect immediately. Mode transitions to Setup Mode or Audit Mode may either take effect immediately (recommended) or after a reset. For implementations that require a reset, the mode transition shall be processed prior to the initialization of the SecureBoot variable, and the SetVariable() workflow shall be as follows:

If the variable has an authenticated attribute, it shall be authenticated as specified, and failure will result in immediate termination of this workflow by returning the appropriate error.

Check secure storage to determine if a Secure Boot Mode transition is already queued. If a transition is already queued, terminate this workflow by returning EFI_ALREADY_STARTED

Queue the request to secure storage

The Secure Boot Mode and Policy variables SHALL remain unchanged

Return EFI_WARN_RESET_REQUIRED.

After reboot, if the transition is successful, Secure Boot Mode and Policy variables will change accordingly. If the transition to lower security modes is rejected or fail, the workflow is terminated and the Secure Boot Mode and Policy variables remain unchanged