Split out of #962 (now closed) as section 3. Sections 1 and 2 of that issue are
finished; this is the long game and it has been carried over unchanged so nobody
re-derives it.
Why this exists
A Microsoft-signed FOG shim is the only route to Secure Boot trust that requires
nothing of the admin. Every other path FOG now ships — MOK enrolment, Setup Mode
db writes (FOGProject/fos#134) — asks for either a technician visit or a
firmware trip, because FOG's certificate has to get trusted somewhere and only
Microsoft's signature is trusted everywhere by default.
The gate: settle the UKI question first
Nothing else here is worth starting until this is answered.
FOS boots as a bzImage, plus a command line supplied over the network, plus an
unsigned ext2 initrd. Lockdown in integrity mode is the accepted mitigation and
rhboot/shim-review does not literally mandate a UKI — but for a payload shaped
like this a reviewer will push hard, and reasonably so: a signed kernel that will
execute an unsigned initrd handed to it by whatever answered DHCP is close to the
thing shim exists to prevent.
If FOS cannot move to a UKI, the application probably is not winnable, and the
lockdown patch below buys nothing on its own. So this is a design question about
FOS's boot shape, not a shim-review paperwork question, and it comes first.
The rest, once that is settled
What the review actually costs
rhboot/shim-review wants an EV certificate from the Microsoft Hardware Dev
Center, HSM or smartcard key custody, a security contact with a PGP key, a build
from the shim 16.1 tarball with a frozen-toolchain Dockerfile, a vendor SBAT
entry, and a signed kernel that enforces lockdown. The review is volunteer-run,
two to three months minimum, and carries permanent CVE and hash-revocation duty
afterwards.
That last part is the one to weigh honestly before starting: it is not a project
that finishes.
Also recorded from #962
Fleet-scale db enrolment by firmware tooling is mostly a dead end as a
general answer — db/dbx updates must be signed by a private PK or KEK, and
on OEM hardware that key is Microsoft's, so there is no owner-usable path without
setup or custom mode. Dell exposes programmable custom-mode import via Dell
Command | Configure and iDRAC; Lenovo supports clearing PK into setup mode but
unattended cert push is unconfirmed; HP consumer lines have no enrolment mode at
all. The parts of that which FOG can act on are tracked as phase 3 in FOGProject/fos.
Split out of #962 (now closed) as section 3. Sections 1 and 2 of that issue are
finished; this is the long game and it has been carried over unchanged so nobody
re-derives it.
Why this exists
A Microsoft-signed FOG shim is the only route to Secure Boot trust that requires
nothing of the admin. Every other path FOG now ships — MOK enrolment, Setup Mode
dbwrites (FOGProject/fos#134) — asks for either a technician visit or afirmware trip, because FOG's certificate has to get trusted somewhere and only
Microsoft's signature is trusted everywhere by default.
The gate: settle the UKI question first
Nothing else here is worth starting until this is answered.
FOS boots as a
bzImage, plus a command line supplied over the network, plus anunsigned ext2 initrd. Lockdown in integrity mode is the accepted mitigation and
rhboot/shim-reviewdoes not literally mandate a UKI — but for a payload shapedlike this a reviewer will push hard, and reasonably so: a signed kernel that will
execute an unsigned initrd handed to it by whatever answered DHCP is close to the
thing shim exists to prevent.
If FOS cannot move to a UKI, the application probably is not winnable, and the
lockdown patch below buys nothing on its own. So this is a design question about
FOS's boot shape, not a shim-review paperwork question, and it comes first.
The rest, once that is settled
left inactive
security_lock_kernel_down()is not in mainline, nor isefi_enabled(EFI_SECURE_BOOT). Seedocs/adr/0010-secure-boot-kernel-hardening.mdin Build the lockdown LSM into the FOS kernel, without activating it fos#131for the hook point and a smaller single-file alternative.
What the review actually costs
rhboot/shim-reviewwants an EV certificate from the Microsoft Hardware DevCenter, HSM or smartcard key custody, a security contact with a PGP key, a build
from the shim 16.1 tarball with a frozen-toolchain Dockerfile, a vendor SBAT
entry, and a signed kernel that enforces lockdown. The review is volunteer-run,
two to three months minimum, and carries permanent CVE and hash-revocation duty
afterwards.
That last part is the one to weigh honestly before starting: it is not a project
that finishes.
Also recorded from #962
Fleet-scale
dbenrolment by firmware tooling is mostly a dead end as ageneral answer —
db/dbxupdates must be signed by a private PK or KEK, andon OEM hardware that key is Microsoft's, so there is no owner-usable path without
setup or custom mode. Dell exposes programmable custom-mode import via Dell
Command | Configure and iDRAC; Lenovo supports clearing PK into setup mode but
unattended cert push is unconfirmed; HP consumer lines have no enrolment mode at
all. The parts of that which FOG can act on are tracked as phase 3 in FOGProject/fos.