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

On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot?

Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then you lose the ability to access the data on the drive altogether. While if it isn't you can still recover the data from the drive.



The TPM 2.0 spec has the ability to duplicate keys from one TPM to another for this type of use case. It of course requires the key policy to allow for duplication, so you have to plan ahead of time, but it is possible.


The article already mentions both of those challenges, and outlines practical solutions/mitigations to both--can you be more specific about what you didn't like?


To be honest I hadn't read the whole article when I posted that, I'd only made it about halfway through. Now having read the whole thing, regarding a failing TPM, having a recovery key seems like a fine solution, I just didn't know if that was possible.

Regarding initrd, the idea of a base image plus extension images might work. Although I still have questions. Are these extension image signed by the vendor or the host? If the former, how do DKMS modules work? That isn't an edge case, the nvidia propriatary drivers, some wireless drivers, virtualbox, and sysdig for example all rely on DKMS (at least on ubuntu). And how does that system handle competing drivers? Should the base initrd use the nouveau drivers or the proprietary nvidia drivers, or does the user need to load an extension image to choose? And for that matter the base initrd you want for a server will probably be pretty different from what you want for a laptop.




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

Search: