Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.


That depends on which PCRs you bind your TPM-backend encryption key to. See this list: https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...

As an example, Arch Wiki encourages you to bind to PCR 0+7: https://wiki.archlinux.org/title/Trusted_Platform_Module#sys... ... both of those are firmware-level PCRs, not OS ones.


PCRs 0+7 might not be sufficient if you don't have an up to date dbx (revocation list) - older versions of shim won't (I think) extend into PCR 7 enough information on what they chainload. This means a malicious bootloader could fake the correct PCR extensions.

Updating dbx to a version which revokes versions of shim with this issue would fix this I think, as would including PCR 4 in the list bound to, to make doubly sure that the version of shim is new enough not to present a risk.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: