|
|
Subscribe / Log in / New account

Other long term problems

Other long term problems

Posted Jun 7, 2012 10:27 UTC (Thu) by etienne (guest, #25256)
In reply to: Other long term problems by pjones
Parent article: Fedora, secure boot, and an insecure future

> Flash ... write enable physically disabled.

That is the problem, if it is physically disabled (by a bit which cannot be reseted without complete power-down) nobody can update the key to revoke anything.
If the bit can be reseted with a magic bit manipulation then only few people know how to do it, black-hat paid $250k a shot are part of those mens.
On a side note, I tried to verify the CRC32 of the FLASH at each boot in real mode (no interception possible), but it is completely unusefull: CRC32 changes at each boot, it seems something different (boot counter?) is stored each times the machine reboots.
Basically, we would need a publicly described "file-system format" of the FLASH (simple filename/address/length triplet without non-contigous files and without automatic file creation/growing management) - so that at least the bootloader can display a warning when something which should not change has changed...


to post comments

Other long term problems

Posted Jun 14, 2012 14:09 UTC (Thu) by JanC_ (guest, #34940) [Link] (1 responses)

The *current time* is updated quite often indeed... ;)

Other long term problems

Posted Jun 14, 2012 15:45 UTC (Thu) by etienne (guest, #25256) [Link]

Why would you write the current time in the FLASH? It would be out of date pretty quickly... The copy of the ACPI variables in RAM are updated all the time, as needed, but it is not my point.
What I noticed is that the FLASH CRC32 was switching in between two values, then I tried to limit the FLASH checkuming part to what is visible (real-mode address 0xE000:0000 to 0xFFFF:0000) but it did not work neither.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds