
Ubuntu 17.10 corrupting BIOS of many Lenovo laptop models - muxator
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
======
sandGorgon
For those who dont remember, this has happened in the past with systemd -
[https://github.com/systemd/systemd/issues/2402](https://github.com/systemd/systemd/issues/2402)

At the time systemd got a lot of serious heat and poettering got called names
for something that was not systemd's fault to begin with.

> _To make this very clear: we actually write to the EFI fs in systemd.
> Specifically, when you issue "systemctl reboot --firmware" we'll set the
> appropriate EFI variable, to ask for booting into the EFI firmware setup.
> And because we need it writable we'll mount it writable for that._

~~~
dogecoinbase
It absolutely was systemd's fault -- systemd regularly half-implements or
changes default behavior in ways that "should" be okay, but aren't okay,
because they don't know why the fence was built (in the Chestertonian sense).
Systems programmers should know the history of their discipline.

~~~
mjg59
I wrote the EFI variables filesystem. It was intended to be mounted
read/write. Systemd did nothing wrong whatsoever in mounting it read/write,
and mounting it read only would have broken all the existing userland that
handles EFI variables.

~~~
gens
What userland is it ? And why is it a problem for that userland to mount it
itself ?

Why would you even write to efi ? Maybe at boot, i don't know, but certainly
not while running ? Not all the time ? Oh i hope there isn't a single program
that continuously writes to efi.

In my opinion systemd _is_ at fault, as they aim to be the "system" and yet
every once in a while prove that they don't know shit.

EDIT: A program that changes the boot order is all i can think of. (I'm not
the one who knows best, on this topic)

~~~
mjg59
> What userland is it ? And why is it a problem for that userland to mount it
> itself ?

At the very least, efibootmgr. The problem with userland mounting it itself is
that it has no code to mount it itself because even before systemd everybody
mounted the filesystem read/write.

> Why would you even write to efi ? Maybe at boot, i don't know, but certainly
> not while running ?

A whole bunch of reasons. Maybe you want something that's tied to the hardware
without relying on the OS (eg, tpmtotp). Maybe you want to be able to
differentiate between a clean and unclean system shutdown. Maybe you want to
indicate that the system should install a firmware update next time it's in
boot services.

> In my opinion systemd is at fault, as they aim to be the "system" and yet
> every once in a while prove that they don't know shit.

At the time this issue was raised, _nobody_ knew shit. We had no idea that
removing certain variables might prevent a machine from booting. If we had
done, I'd have written the filesystem differently.

> I'm not the one who knows best, on this topic

I wrote the code in question. I am one of the people who does know best on
this topic. Systemd did nothing wrong.

~~~
gatmne
Couldn't the filesystem be mounted as read-only during normal operation, and
only remounted temporarily as rw when necessary? Tools that write to this
filesystem tend to have the necessary privileges to do so.

Leaving efi writable like this by default strikes me as a very poor and
unsubstantiated design decision.

~~~
mjg59
> Couldn't the filesystem be mounted as read-only during normal operation, and
> only remounted temporarily as rw when necessary?

Yes, except that none of the tools in question have any support for doing that
and so mounting the filesystem read-only rather than read/write would break
them. And congratulations, now you've still got a window where something can
still break everything while the filesystem is mounted read/write (what
happens if the tool crashes during that phase?).

> Leaving efi writable like this by default strikes me as a very poor and
> unsubstantiated design decision.

Yes with hindsight that's entirely accurate and it was also _my_ decision and
nothing to do with systemd.

~~~
gatmne
> now you've still got a window where something can still break everything
> while the filesystem is mounted read/write

I agree, but I'm also sure you would agree that a small window were things can
go horribly wrong is much more preferable than than a perpetually open one
(sudo and friends stand testament to this).

Please bear in mind that my comments are in no way an attack on your person or
one directed at systemd. What I want is to find a workable solution or, at the
very least, a compromise to prevent this type of issues from occurring. I
strongly believe that protecting hardware is a core responsibility of any
operating system.

Would it be reasonable for me to ask you to coordinate with all the major tool
developers to gradually phasing out this behavior? As in both the filesystem
and tooling continue to support both current semantics and a newer version
until the older semantics can be safely disabled. This is how support tends to
get phased out from the kernel for obsolete hardware.

Issues of this type have reared their heads many times already and I expect
they will continue to occur if the underlying reason is not addressed. As the
person who has the ability to do something about it, I urge you to reconsider.

~~~
mjg59
> I agree, but I'm also sure you would agree that a small window were things
> can go horribly wrong is much more preferable than than a perpetually open
> one (sudo and friends stand testament to this).

What's even more preferable is a situation where the kernel doesn't let you do
the damage in the first place, which is what we have now.

------
codemac
EFI allows for OS's to modify probably too much, and the state of EFI
implementations aren't defensive enough.

I personally _would_ blame Lenovo for releasing something so brick-able.

~~~
mcny
I managed to brick my Asus N61JV-X2 by updating the bios using their official
bios update software. (Specs if you're curious
[https://www.anandtech.com/show/2962/asus-n61j-x2-optimus-
gt3...](https://www.anandtech.com/show/2962/asus-n61j-x2-optimus-gt325m-meets-
arrandale) )

I also learned that backup bios chips were a thing but not usually available
on a notebook PC

~~~
vetinari
I managed to brick Thinkpad X230, flashing BIOS update that came via TVSU.
Now, that's an achievement :/

~~~
ct0
Here I was thinking that the 230 was indestructible

------
julienfr112
How could an OS corrupt a BIOS ? BIOS is in a <strike>higher</strike> lower
(see alex_duf comment) level than OS, and then, should no be modified by any
program, except maybe by an update program, and only with a firmware signed by
lenovo.

~~~
nikbackm
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.

~~~
gerdesj
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.

~~~
msl
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](https://github.com/systemd/systemd/issues/2402)

~~~
merb
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.

~~~
JdeBP
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](https://news.ycombinator.com/item?id=11152880)
where you will find Matthew Garrett xyrself participating in the discussion.

------
just1nn
17.10 was the absolute most buggy software that I have installed from
Canonical. I tried it on Dell hardware (+ Apple Hardware, + A VMware VM on X64
+ VirtualBox on OSX, etc) that does just fine with Fedora, Arch, Gentoo, and
it was constantly prompting me to send error reports, killing processes, etc.
I just flipped from using the "latest" vs the LTS versions at home because of
this version, specifically.

~~~
gitgud
Not the worst Ubuntu version, but I had a lot of issues with the default
protocol being Wayland [1].

This broke a few programs I use, [2] mainly the screenshot application
"Shutter". Most users don't realise it became the default, so their apps just
stopped working... bad decision in my opinion.

[1] [http://www.omgubuntu.co.uk/2017/08/ubuntu-confirm-wayland-
de...](http://www.omgubuntu.co.uk/2017/08/ubuntu-confirm-wayland-
default-17-10)

[2] [https://askubuntu.com/questions/971273/screenshot-feature-
of...](https://askubuntu.com/questions/971273/screenshot-feature-of-shutter-
doesnt-work-after-upgrading-to-ubuntu-17-10/971278)

------
tcfunk
My XPS 13 Developer edition had something similar happen to it shortly after
upgrading to 17.10. However I think this was circumstance, and that the real
culprit was a bad BIOS update from Dell which removed all entries from the
boot list (or something to that effect).

~~~
wakeywakeywakey
What did you do to recover?

~~~
cevn
(not the parent, but I had the same laptop with the same problem) I
reinstalled Fedora. I could have probably recovered the grub bootloader
manually, but I wasn't really keen on sitting there for a few hours. All my
data was backed up anyway.

~~~
wakeywakeywakey
It still allowed you to boot from USB? How do you recover if you lose that
option (other than sending in your laptop to be reflashed)?

------
chisleu
It isn't Ubuntu doing it. It is Intel and Lenovo.

Owner of a $3k Lenovo P50 here that was "Linux compatible" but a stake xeon
that had been useless on Linux until the latest Fedora.

------
1001101
Might be a coincidence, but I haven't been able to get into my Toshiba's BIOS
since moving to 17.10. Every time I try and enter the BIOS config menu, it
reboots.

------
tinus_hn
Just like all the other UEFI implementations, the Lenovo one is probably a
giant piece of crap.

The main problem is Windows because it allows manufacturers to get away with
the 'it runs Windows so it's good enough to release' mindset.

~~~
user5994461
The main problem is Linux. Linux cannot be tested, it designates hundreds of
variable setups of distributions, kernels and tools. It's not possible to test
anything against that.

Lenovo supports redhat and ubuntu, that's already a lot.
[https://support.lenovo.com/gb/en/solutions/pd031426](https://support.lenovo.com/gb/en/solutions/pd031426)

~~~
tinus_hn
They shouldn’t support RedHat, Ubuntu and Windows. They should provide a
solid, compliant UEFI implementation and then Windows, RedHat Linux and Ubuntu
Linux will support them.

------
ericfrederich
Good thing I saw this. I was thinking about installing Ubuntu or Mint on my X1
Yoga during the holidays. I'll hold off now or do some more research.

~~~
chrissnell
For what it's worth, I haven't had this problem with Arch Linux on my ThinkPad
T470s or P50 and I did a fresh install on the P50 this week. Arch has really
nice ThinkPad support and documentation, too.

------
ezoe
It looks like Lenovo's problem.

~~~
antoncohen
Yes, while Ubuntu has regressed, the root of the problem seems to be a Lenovo
logic error where Lenovo resets the BIOS settings if the write protection bit
is set to read/write.

[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147...](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/173)

------
vegbrasil
Is it safe to install on a Dell XPS 15?

~~~
bproven
I upgraded my XPS 15 (9550) from Ubuntu 17.04 to 17.10 about a week ago and
have had no issues so far. Actually, I find it a little less buggy on my XPS
than 17.04 was - overall I am pretty happy with it. Of course YMMV - my specs
are below

\----------------------

Dell BIOS: 1.5.1

i7-6700HQ CPU @ 2.60GHz

16GB RAM

Intel® HD Graphics 530 + NVidia

512GB SSD

~~~
vegbrasil
Did you manage to get both GPUs to work?

~~~
pxc
It's a bit of a pain, but quite doable on most distros, if you know your way
around. I just did it on two distros for my ThinkPad 25: with openSUSE it was
part of a weekend of playing around with it and setting it up, and on NixOS it
took an hour or two to set up how I like.

The real problem, imo, is that all of the solutions work badly (they either
work at a performance penalty (as with Bumblebee) or require a separate X
server for each GPU).

This is entirely a result of NVIDIA's refusal to implement decent support. The
Nouveau drivers offer proper PRIME support, which yields an experience more
like that on Windows in terms of workflow and the amount of setup (virtually
none) required, but they have their own performance problems. Hybrid graphics
with AMD GPUs apparently works nicely with whatever drivers you like, granted
that the software stack is sufficiently up to date on your system.

