Master the fundamental concepts of the boot process: theory through this focused micro-challenge.
You have read the whole brief, and the concepts above stay free on every task. Writing and running the code needs a plan.
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
Every task includes starter code, theory, and hidden tests so you can implement and verify locally in the browser.
How it worksSecure Boot uses firmware-stored keys to verify each boot stage before execution. The platform key (PK), key-exchange keys (KEK), and signature databases (db/dbx) form a chain of trust from power-on to the OS loader. For example, a shim bootloader signed by a CA in db can load a Linux kernel only if the kernel's signing certificate is also trusted.
.efi must carry a valid Authenticode signaturedbx blocks known-bad hashes and certificatescLoading…
You will document how Secure Boot keys and signatures gate each loader stage. This exercise requires explaining PK, KEK, db, and dbx and how a signed .efi binary is accepted or rejected at boot.
UEFI Secure Boot checks every .efi image against two databases before running it: db, the trusted signers, each with an expiry date, and dbx, revoked hashes. Apply its rules in this order:
HASH EXPIRY, with the expiry as YYYYMMDD.HASH.NAME HASH DATE.Each database has at most 16 entries.
One line per image:
shim: ACCEPTEDevil: REJECTED (hash in dbx, revocation overrides db)malware: REJECTED (no signer in db)oldloader: REJECTED (db entry expired 20260101)Then verified 3 image(s), db=2, dbx=1.