Well, it's still a solution to problem which shouldn't exist in the first place. Before UEFI, x86 boxes were hard to brick unless you really knew what you were doing.
I found the one that described removing the "backup battery" under the wristrest. Once I removed that, and replaced it... everything came back together, and the laptop booted (with generic factory settings).
Difficulty in getting to the battery aside, he just did a regular CMOS reset, the standard technique for getting otherwise unusable systems back to a good state.
Now that you posted this, I think I recall one friend telling me that hibernation killed his laptop. But this was over 10 years ago and I only know about one such incident.
OTOH, what UEFI gave us is basically a portable and convenient API to brick any machine from any OS.
> These hardware vendors at all levels - storage controllers, chipsets, radios, and more all have absolutely no QA on their code
Hardware vendors do have QA, but it's mainly about ensuring that things work, not about trying to break them in every possible way. Safety and security seems to be notoriously hard for people who have been taught how to make things work, but not how to make them fail.
Which is exactly why it would be so valuable to have that code in the open.
I know I'm repeating myself but I still think the interations between OpenWRT and the Chinese firmware vendor that was pushing Linksys firmware upstream is a valuable example of why open source is valuable in this context even if you are not intimately involved in the development, testing, or inspection of such code. Public code by its nature requires more scrutiny and its harder to get people to accept something broken or poorly written when they can see just how bad it is.
If you want to develop awful coding habits, only work with people who never develop free software. If you want to have really good habits, work in a very popular free software community, because when your work is in the open like that and everyone is a volunteer nobody is going to put up with crap.
> I just know the next laptop I buy will be whatever the highest end liberated Chromebook at the time is, preferably without cancerous firmware blobs that control everything, but that seems unlikely considering how anti-freedom Intel is.
Yep, I don't think you'll find x86 Chromebooks without blobs. Nowadays the only way Intel provides to boot their hardware is "here, take this binary and put it at the beginning of your BIOS".
I'm fine with ARM, hopefully future iterations of the ASUS C201[1] are portable to Libreboot in the future by the time I'm shopping for a new laptop. It won't be for a while, I hate giving these scum freedom denying companies my money for locked down puke.
The thing I find particularly hard to grok is that they came up with this idea of putting disk-specific boot information on the motherboard. Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.
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.
Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.
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.
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.
Drives have had CHS values printed on them since the very beginning. It does mean you have to open the case to read it, but you do have to open the case to reset CMOS anyway...
But the problem of drive geometry detection essentially disappeared with IDE autodetection, which quickly became the norm sometime in the early 90s.
> 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.
But isn't boosting the security of PC systems a selling point of the UEFI/Secure boot implementation? Or was that all a lie?
> But isn't boosting the security of PC systems a selling point of the UEFI/Secure boot implementation? Or was that all a lie?
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.
As long as they still let you turn off Secure Boot, I don't see why you can't just put a BIOS CSM in your EFI system partition and load it before proceeding with business as usual.
tl;dr: This can permanently brick some/many/all? UEFI devices. Three cases confirmed so far on Lenovo/MSI/unknown hardware.
Linux distribution other than Arch are likely to be affected as well because systemd is hardcoded to mount the EFI variables pseudo-filesystem with RW access on every boot.
