This kernel model was written for the explicit purpose of modifying the BIOS[1]. The module writer makes the recommendation of not enabling in KConfig[2]. The question is did Ubuntu enable it by default and if so, why?

[1] https://github.com/torvalds/linux/blob/master/Documentation/...

[2] https://github.com/torvalds/linux/blob/8afda8b26d01ee26a60ef...

I was really going to ask that - it shouldn't even be possible.

I would look at the wonders of UEFI.

One more reason to hate UEFI

https://superuser.com/questions/742334/is-there-a-scenario-w...

https://archive.fo/g9DKx https://screenshots.firefox.com/QiHbjMEHAIrb9Wt3/thenextweb....

We usually refer to the BIOS as a lower level than the OS.

It's also possible to bridge from a higher level to a lower level, typically when flashing your BIOS, chances are you're doing it from the OS (it's usually possible to do it at a lower level though).

In this case it looks like a kernel module that does exactly that has been enabled before being ready from prime time. Woups.

Okay, fine: "Why is a kernel module writing to my BIOS"?

To update your BIOS. In this case the kernel module doing that was buggy and not ready. The real question is why the module was enabled by Canonical.

Again. Why is a kernel module writing to the BIOS?

The BIOS is not to be messed with by user software or the OS. It should be signed and only changed by the manufacturer tool to update it.

To update the BIOS. That was its express purpose. Note that the kernel module was contributed by the BIOS manufacturer itself.

Why are you so enamored with giving up control of your hardware to the laptop manufacturer?

From never-fixed bugs in manufacturer's firmware to setting up things to happen on the next boot, there are innumerable reasons to write to the BIOS from a higher level.

The BIOS update process is usually an afterthought held together by string, and appears to the OS as mysterious peripheral. Every now and again some manufacturer releases hardware where Linux simply trying to probe the hardware bricks the machine.

Well, you could at one time brick your computer by by executing an ill-advised "rm -rf" from Linux.

Made the news some years back I think.

You're referring to this?

https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

I guess this explains why I was not able to boot by USB the other day. I tried out Ubuntu 17.10 on my Y50-70 recently. :(

You can do a similar thing in any OS - delete the vast majority of your file system by running a command as root/administrator and ignoring warnings. FYI rm -rf no longer recurses upwards (. and ..) and hasn't done so for a very, very long time.

This problem is about breaking the BIOS in some way, something that you should not be able to do.

This is in reference to the issue a few years ago where it was easy to wipe EFI vars via /sys, which would happen if you rm -rf / .[1] Wiping the EFI vars would brick your system.

[1]: https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

You used to be able (maybe still are?) to "rm" the files on a mounted efivarfs. See the relevant systemd issue ([1]).

[1] https://github.com/systemd/systemd/issues/2402

well windows can get write access to these aswell. (just not by using rm or any other tool to remove files by default). I think this is a big difference and should probably be addressed. make /sys read-only and allow to write them differently with a interface where I need to call THIS_METHOD_CAN_BREAK_A_SYSTEM_IF_USED_INCORRECT_WRITE_SYS() command. but well, systemd guys will/won't do that.

It wasn't a systemd thing. The people who relate the tale as if it were a systemd thing or something that the systemd people did are ill-informed. Much as in the case of the headlined bug at hand, it was entirely a kernel thing. This was even stated outright at the time by the creator of that particular kernel mechanism.

To learn the real story, go and read https://news.ycombinator.com/item?id=11152880 where you will find Matthew Garrett xyrself participating in the discussion.

Not any more. Non-spec variables are initially immutable, so can't be removed until you toggle that.

And which you could do a few years back by rm-ing files from a virtual device that mapped to BIOS configuration.

10 years ago was updating BIOS of my Asus motherboard from my Windows OS, with a .exe program.

10 years ago was 2007

:(