Linux bricking/breaking UEFI/BIOS is an egg on OEM’s faces too

Apparently Ubuntu was bricking some Lenovo laptops because it was screwing up the BIOS causing things like setting to not be saved when…

Linux bricking/breaking UEFI/BIOS is an egg on OEM’s faces too

Apparently Ubuntu was bricking some Lenovo laptops because it was screwing up the BIOS causing things like setting to not be saved when exiting and some other issues. This isn’t the first time we’ve seen a Linux distro be able to mess with the BIOS or even brick a BIOS/UEFI, there was the rm-rf bug on some machines.

OS Modification

I think people should get on the Linux developers to be careful and try to do a better job at testing; however, this seems like a major problem with OEM’s too. Why is this OS allowed to cause that type of damage? I know some of you might think it’s silly for me to point blame at them too, “it’s Linux doing the damage.” That’s just stupid.

Malware

Let’s take a Windows machine and write some malware. Now, either someone gave it administrative rights, or it took advantage of a privilege escalation vulnerability. That malware was written to target the most popular BIOS/UEFI, not the first malware to do that either. If I can, with admin/root force changes on the BIOS/UEFI, why can’t I force an infection. Obviously my changes are persistent through reboots. Why not infect any OS installation that BIOS/UEFI sees?

Proper Seperation

If I were to write a BIOS/UEFI I’d surely not trust the OS. There should be a clear separation. If the OS gives me a BIOS/UEFI update it better be signed, why in 2017 would I not have signed code?? If I need to provide some functionality for the OS to change parts of my settings, it better be separated from the rest of my code and not trusted. It should be properly ringed.

Of course, the code is becoming more complex and mistakes are being made. These mistakes can lead to a physical computer that you can’t trust anymore.