4 ms·
An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist th
by g_p 5y ago
An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs?
If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys.
I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database.
Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?
- Foxboron 5y agosysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it. Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot. $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l 7 This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory. https://github.com/Foxboron/sbctl/issues/85#issuecomment-886539689 https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...
- g_p 5y agoGood idea RE the TPM event log - that should show the definitive perceived hash of the option ROM. Will need to see if I have any computers that require an Option ROM - somehow I suspect shipped-with-Linux Dell XPS laptops aren't going to be good test candidates.