5 ms·

Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!

by Mic92 11y ago

ajross 11y ago
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.
- kbenson 11y ago
  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."
  - ktRolster 11y ago
    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.
    - ambrice 11y ago
      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.
    - GhotiFish 11y ago
      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.
    - cbd1984 11y ago
      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.
  - eikenberry 11y ago
    +1 The kernel developers are continuously working around bad behaviour by bios/firmware authors. It is the right place.
- captainmuon 11y ago
  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.
- spoiler 11y ago
  > 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-Models.txt https://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio... [archwiki]: https://wiki.archlinux.org/index.php/Category:Laptops https://wiki.archlinux.org/index.php/Category:Laptops

Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!

by Mic92 11y ago

Instead of flaming systemd developers for mounting efivars read/write, the kernel is the right place to fix the problem for everybody!

ajross 11y ago

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.

kbenson 11y ago
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."
- ktRolster 11y ago
  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.
  - ambrice 11y ago
    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.
  - GhotiFish 11y ago
    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.
  - cbd1984 11y ago
    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.
- eikenberry 11y ago
  +1 The kernel developers are continuously working around bad behaviour by bios/firmware authors. It is the right place.
captainmuon 11y ago
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.
spoiler 11y ago
> 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-Models.txt https://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio... [archwiki]: https://wiki.archlinux.org/index.php/Category:Laptops https://wiki.archlinux.org/index.php/Category:Laptops