3 ms·
In my view this is a result of hardware not actually being "hard". It would be far better to have a bug that comes back after a cold boot, as part of a known s
by 1xtjjlunab 12y ago
In my view this is a result of hardware not actually being "hard".
It would be far better to have a bug that comes back after a cold boot, as part of a known starting state, than to have a mechanism for "updates" (running software) that is inaccessible to the user/programmer. A static bug can be worked around, but a moving target is harder to compensate for, particularly if it is not viewed as user-programmable (for lack of documentation, or license, etc).
To me, this demonstrates that the proper place for security is in software, at as high a level as possible for the purpose. Even secure boot is too low. Boots should be insecure, but repeatable. Turning a computer on should give full control - only then can you lock it down (whatever that means to the user...). Secure boot, if you want it, should just be a bootloader that verifies a payload, thereby protecting itself - not a BIOS-integrated feature, where the BIOS is opaque.
A feature-full BIOS would only makes sense if it were immutable (and even then, there would be disadvantages), or (at the other end of the spectrum) if it were as programmable as the rest of the system - but until then, any unnecessary complexity or "features" are downright harmful.
- morcheeba 12y agoTo do that, you'd also have to harden everything - including the hard drive's firmware - so you get the proper boot sector. Not all bios bugs can be worked around in firmware -- if the memory controller isn't initialized correctly, all processing is suspect. And if the manufacturer can't fix a bios, then it falls on the shoulders of the OS writers -- who do not have neither the motivation to fix 100's of board-specific problems. Worse yet, if I wanted to inject malware, I would pretend to be a motherboard manufacturer and submit bad kernel code to beleaguered OS people.