Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.
Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.
The "low level hardware settings" were always stored on the motherboard, ever since the PC/AT. The big difference is that a simple CMOS reset would reset those to the defaults, and the machine would be bootable with the defaults. In the old days some errant program could corrupt CMOS (writes to port 70h/71h), but that was relatively easily fixed.
With this UEFI stuff, it appears the configuration data is stored in nonvolatile RAM, there's no easy way to "reset to defaults", and the defaults are either missing/unusable.
The good-old-days weren't all Wine and Roses. For example, there was this: http://webpages.charter.net/danrollins/techhelp/0054.HTM
If you wiped out CMOS, a "simple CMOS reset" was not sufficient to allow booting, because knowledge of the type of disk you had installed was lost.
Sure, you could iterate thru those preloaded disk types and stumble upon the correct one. BUT, having a fixed selection of types proved to be too limiting. So there was a scheme to add drives types. That info was also stored in CMOS, so if you lost that, it was quite difficult to restore the configuration:
Newer BIOSes provide a means to define a custom
setting. The setting will be stored in an
undocumented location in CMOS memory (and is lost
if the battery ever fails -- so write it down!)
It wasn't an insurmountable problem. It simply meant that you had to come up with a few bytes, perhaps by calling the manufacturer or integrator. But this was in the days before Google, so it wasn't easy to find this info with a quick search.But the problem of drive geometry detection essentially disappeared with IDE autodetection, which quickly became the norm sometime in the early 90s.
But isn't boosting the security of PC systems a selling point of the UEFI/Secure boot implementation? Or was that all a lie?
If you are bothered by people booting unauthorized disks on your hardware, enforce signature checking on OS images.
SecureBoot is a farce. 99.99% of users will never be the target of the attack it supposedly prevents and the other less than 0.01% of users know who they are.
On top of that it doesn't even work. The premise is for it to be used in combination with full disk encryption (since otherwise the attacker could just remove the drive), to protect the integrity of the boot shim that prompts you for the decryption password so the attacker can't replace it with one that gives the attacker the password. But there is necessarily an unencrypted analog connection between the human and the computer and the attacker can still capture the password that way.