Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

No, the firmware is the right place to fix the problem. A BIOS that bricks itself because of within-specification deletion of variables via a standard API is just plain broken.

But in the real world no one ever fixes firmware bugs, so this is the best we can do.

I think we can all compromise on "The firmware is the right place to fix the problem, the kernel is the right place to mitigate the problem."

Not really. Systemd could have fixed it, but it would have been a lot of work and a hack. The Linux kernel team could have fixed it, but it would have been a lot of work and a hack. The hardware manufacturers should have fixed it, but they don't care.

The Kernel team showed they are professionals by stepping up and doing the work.

Bricking is a rather extreme firmware bug, but even if it didn't brick itself - if it just lost a bunch of information (Boot list, Vendor information, Time, BIOS settings, Windows activation data / preinstalled keys... I don't know all the kinds of stuff you can put in there.)... wouldn't that also be bad? I would never expect to be able to cause that by deleting a directory. So by the principle of least surprise, this shouldn't be mounted by default.

So on a non-broken BIOS, there is "technically" no bug - but the pieces (BIOS, Kernel, Systemd) come together to make a bad design.

+1

The kernel developers are continuously working around bad behaviour by bios/firmware authors. It is the right place.

> But in the real world no one ever fixes firmware bugs, so this is the best we can do.

PREFACE: This is an anecdote, but I do believe it reflects on general state of hardware vendors, because when I Google'd, it showed that people had similar, if not worse problems than I did.

And this is so incredibly sad. Especially when you buy a $2.5k laptop which only works with Windows (with quirks).

I bought a laptop^[model] on which you couldn't even install another OS because of a crippling firmware bug. It wasn't until a shit storm on their forums that they released a firmware update which fixed the issue (which was that the SATA controller was stuck in RAID mode, and you couldn't change it to AHCI), which prevented any OS from being installed (even window, that was installed already, which is bizarre) because no OS could recognise the PCIe NVMe M.2 SSDs.

After the update was released, I did happily install Linux on it, but the ACPI DSDT was so broken, I didn't know where to begin with fixing it (apart from this whole hardware stuff being outside of my domain). Other than that jack detection is jack shit (pun intended). I literally can't use my headphones without special OEM or Realtek software (forgot which) on Windows, and I can't use them at all on Linux because there's no equivalent. I tried playing with various modes^[modes] and output configurations, but to no avail.

Also, on Windows I hear a subtle scratchy sound from somewhere in my laptop, but I don't hear it on Windows. I noticed it the most while moving my USB mouse or when there's a lot of CPU intensive work. No, all the solutions recommended online didn't work, and this is apparently an issue with Windows on Asus/Realtek for years, if not decades.

Furthermore, there's a bizarre flicker which subtly intensifies and then subtly goes away on Windows (and it interestingly happens only in some applications which appear to use GPU acceleration) which doesn't happen on Linux (even during an intensive OpenGL benchmark followed by a WebGL benchmark).

The things I thought I'd have most issues with (the GPU and the Skylake processor) turned out to be the least of my problems. Actually, 0 problems with them. So, kudos to NVIDIA for their proprietary Linux drivers (the novueau ones worked great, too, but I devcided to go for the proprietary ones due to the slight performance benefit).

So, no this isn't a Linux issue to anyone who wants to scream "boohoo linux is bad for consumer PCs". This is all an issue of shitty hardware vendors. There's probably over a hundred models documented on the Archlinux Wiki[archwiki] with all their various quirks and what not. Most of those are actually hardware problems, and there's no way for Linux to fix all these problems without there being some giant database with each laptop model and its quirks and applying configuration fixes, and this would also have to be distro-agnostic or cover various distros to work properly. The only reason why most of it kinda (not flawlessly) works on Windows is because the various Vendors actually cooperate with the Windows developers (I imagine), and its rare that I see them even trying to cooperate with Linux developers; maybe I just missed it, but each time someone does cooperate, it's met with this grand praise that's quite hard to miss, so I doubt I missed it (this excludes certain vendors who have always cooperated with Linux devs, or who specifically write drivers for linux in the first place).

It's so, so solemnly sad that people blame most of this, if not all, on Linux. Especially considering Linux does its best to try and patch this endless stream of oncoming shitty hardware and nobody (not literally nobody, but a very small percentage) sees or recognises that effort.

----------

[model]: ASUS ROG G752, for anyone wondering

[modes]: https://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio...

[archwiki]: https://wiki.archlinux.org/index.php/Category:Laptops

What you mean is: systemd could have fixed it, but it would have been a lot of work and a hack that wouldn't help you when efivarfs gets mounted on a sysv/upstart/openrc system. The kernel was the best place for the fix.

> I literally can't use my headphones without special OEM or Realtek software (forgot which) on Windows, and I can't use them at all on Linux because there's no equivalent.

If the problem is no output at all, it may be just a matter of toggling some HDA codec GPIO or EAPD pin to power up external amplifier chip, which can be done with hda-analyzer. But if it's some combo headphone/mic jack and detection doesn't work then I have no idea.

The DSDT problems aren't just for the high end laptops either - I have a $350 Z3735F system that requires a DSDT edit which I don't understand [1] https://gist.github.com/voltagex/eec041092d719c77483e

systemd can't take all the blame either - I bricked (yes really bricked) one of these by grub installing a "stub" that only booted into grub-rescue on my EFI partition. I can't get into the firmware settings and the rescue loader can't read the partition tables -> bricked unless I can corrupt the EEPROM somehow and force a menu (no CMOS battery in these low-end devices to pull)

disagree. It's not just systemd that could mount efivars as read/write, anyone could. So anyone that does will fall prey to this. It's firmware, and failing that, the kernel protecting you is a good second.

FWIW: that DSDT hack is replacing a constant return value from the first method in the "HAD" device. It was specified to return 0, but now returns 0xf instead. This is almost certainly the _STA (status) method, which informs the OS about the operational status of the described device. I forget the exact meaning of the bottom four bits offhand, but 0xf is the standard value for "device present and operating normally -- use it!".

That it was returning zero would cause the linux ACPI framework to ignore it and not probe its driver. My vague understanding is that windows works differently, and calling _STA is done by the driver, so it's possible to just not do it and still have a working system.

I don't know what the device itself is, but given that the script says "audio" in there it's probably the audio codec.

systemd couldn't have fixed it, because removing the offending code from systemd wouldn't have prevented any other program from, innocently or maliciously, triggering the same bug.

The kernel is where the buck stops when it comes to protecting hardware and, therefore, protecting software from misdesigned and/or buggy hardware. That's been true for longer than most of us have been alive.

PendoPad 11" 'laptop' running Windows 10 Home 32 bit (despite having a 64 bit capable processor).

I replaced the bricked device and I'm going to be a lot more careful this time.

Booting Ubuntu Wily works, but there's no battery (status/charging?), wifi, audio or touchscreen. So if you use the XDA scale it's working perfectly!

I have another Z3735 device (MeegoPad T01 - Intel Compute Stick knockoff), but it's unusable because the clock runs fast, then slow, then fast - enough that an NTP sync makes the clock go backwards and then everything breaks.

These chipsets are turning up everywhere and most of the time the implementation is garbage. I hope Intel did better with the reference implementation/s but I can't afford them at the moment.

Thanks for the tip! I did install hda-analyzer, but never ran it since other stuff came up. The sound thing wasn't such a huge issue, because I just play the music without headphones.

Another problem is that the laptop has a 2.1 sound system (or 4.1 maybe, I am not actually sure?) and the outputs are a bit wonky (which can, apparently, also be fixed/configured with hda-analyzer).

In short, the whole laptop is a mess. I imagine it will be fixed eventually by Linux sound drivers. I am still collecting data to open a bug report on kenrel.org, hoping it helps future people not having to go through all this… bullshit, for a lack of more apt expression.

The idea of multiple vendors making the same "beige boxes" and only competing on price is bad. One of the things on my wishlist for an Intel/AMD branded laptop is a high quality UEFI implementation.

Keep wishing. Even a $1400 Lenovo X1 had terrible UEFI when I used it - what's the point of re-implementing your old keyboard-only BIOS UI exactly if you have mouse support? Dell does better, at least in the business grade products.

I am talking about an Intel/AMD branded laptop.

I get you now - do they exist outside of CES and the Intel employees toting around prototypes?

I know it does not currently exist. The point is that it would be a better idea than what we have now.