Nixpkgs: Make efivarfs read-only by default

[abbradar]

I have become aware of https://github.com/systemd/systemd/issues/2402. It sounds very concerning that someone can brick his motherboard simply by running rm as root, so I propose we add some protection against that. My idea is as follows:

• Make efivarfs read-only via fstab, as was proposed in the upstream issue.
• Patch software that needs access to it to clone a new filesystem namespace and remount efivarfs read-write there. Namespace ensures that it will be read-write only for that process and that it will be cleant up automatically.

So far I can think of very few software that needs such patching:

• systemctl --firmware-setup reboot(I have no idea what this does)
• efibootmgr
• grub-install, but if I remember correctly it works through efibootmgr

The patch would consist of only three consecutive syscalls (I did things like that in our userspace FHS chroot).

I'm willing to implement necessary changes, but I want to know if the community agrees with my concern first, as the issue is somewhat controversial.

Note that I'm very much against discussing whether upstream did the right thing here! Please, let's not continue the flame war and instead agree on whether we want this or not.

[heydojo]

I understand what is being proposed as an issue completely. And I do not agree that anything needs to be done in response.

[globin]

I'm :+1: on making it read-only.

[heydojo]

Am I correct in understanding that your proposal is to prevent people who have purchased hardware which claims to have EFI but which does not have an EFI implementation as per the official specification (of which there are very few) from deleting efivarfs as pid 1?

[abbradar]

Yes. My arguments are:

• Vendors don't provide any information on whether their hardware actually implements the spec good enough (who would say that their hardware is shitty?), so you likely won't know you have broken firmware until it's too late;
• rm -rf / is more likely that you think. For example, I've run that to destroy my system before a system reinstall (because why not, I thought, I'll get to see what happens to the system and it's doomed anyway), and also inside our FHS chroot during debugging (which has /sys mounted). If I would have had broken hardware, I would have used another laptop now ~_^. rm shouldn't be able to brick a motherboard just like that, in my opinion;
• Steps required to protect people from that are trivial (add a line to fstab and patches to several pieces of software which actually write something to it, see above);
• Steps required to bypass this are also trivial (mount -o rw,remount).

Overall, I think effort and inconvenience for us would be low, while possible gratitude of people whose hardware we would save is priceless.

[wkennington]

You could even make wrappers for those programs which create a namespace
and remount inside the namespace, run the application, then tear down. That
should be easier than to maintain software specific code.
On Sat, Jan 30, 2016 at 10:37 AM Nikolay Amiantov [email protected]
wrote:

Yes. My arguments are:

• Vendors don't provide any information on whether their hardware
  actually implements the spec good enough (who would say that their hardware
  is shitty?), so you likely won't know you have broken firmware until it's
  too late;
• rm -rf / is more likely that you think. For example, I've run that
  to destroy my system before a system reinstall (because why not, I thought,
  I'll get to see what happens to the system and it's doomed anyway), and
  also inside our FHS chroot during debugging (which has /sys mounted).
  If I would have had broken hardware, I would have used another laptop now
  ~_^. rm shouldn't be able to brick a motherboard just like that, in my
  opinion;
• Steps required to protect people from that are trivial (add a line
  to fstab and patches to several pieces of software which actually
  write something to it, see above);
• Steps required to bypass this are also trivial (mount -o rw,remount).

Overall, I think effort and inconvenience for us would be low, while
possible gratitude of people whose hardware we would save is priceless.

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/12697#issuecomment-177268783.

[fpletz]

:+1:

[copumpkin]

:+1:

[heydojo]

@abbradar I am still not seeing a case for preventing anyone doing anything accidentally as pid 1.
You can tell if your system is effected by testing it by long pressing the power button to boot until you hear the beeps from the speaker and or reading the manual which came with your system or main board to confirm. It should provide you with the hard reset method.
The number of systems that are effected is very low.
Where possible hardware vendors have released firmware updates to address the problem.

[copumpkin]

@heydojo the question is what's the cost/benefit ratio? How many people even know about the bug linked in the topic, first of all? Are the people who don't know going to know to press the long power button to test if their EFI is implemented properly? Furthermore, what is the benefit of having it be RW by default? To make a couple of rarely used programs a little more convenient? Given the potential downsides, the difficulty of discovering the problem in the first place, and the dubious benefits of keeping RW turned on by default, it seems weird to me to advocate keeping it on by default. It feels like a violation of least-privilege that could be fairly costly in (admittedly very few, but not zero) real scenarios.

What are your reasons for wanting it on by default?

[heydojo]

What are your reasons for wanting it on by default?

If it ain't broke. Don't fix it. As pid 1 you are supposed to be able to be able to do everything.
I don't object to the proposal.
I just disagree that it is necessary.

[copumpkin]

As pid 1 you are supposed to be able to be able to do everything

I don't generally expect to be able to brick the computer via regular file operations without jumping through some serious hoops, even as root.

[heydojo]

The number of machines effected by incorrect efi implementation in this respect is too low to generally expect to be able to brick your efi system.
Turning off a machine and turning it on again and or reading a manual is not what I would consider jumping through hoops.

I can only assume that this reaction by people is the result of a misunderstanding and a forming of bad habits using pid 1. I could just sit here and keep re-iterating that I know that this proposal is unnecessary but it appears that it would also be a waste of all our time.
So I'm going to leave the thread now because I think that the whole "issue" is quite funny and if it makes people feel safer when they are deleting things as pid 1 please go ahead with the proposal.
It is not my place to tell people to drop their bad habits. I have better things to do.

[abbradar]

@heydojo Sorry for summoning you again but I'm interested in your argument about turning the machine off and on (let's agree we disagree on the general "safety net for uid 1" thing, UID 1 nowadays is misunderstood widely and people indeed have a lot of bad habits). If I understand correctly, the issue is that there are some things exposed as EFI variables, that are (a) not expected to be touched at all by the vendor, (b) are not touched by Windows, Linux (in normal circumstances) and other OSes, (c) persist through hard reset and are linked to some place in EEPROM instead of normal CMOS memory and (d) render system unusable if removed. One purely hypothetical example I can come up with is firmware checksums. Why do you think this can be found out by resetting the machine or reading manuals? I must admit I have not fully read original Arch thread about the issue so I may have misunderstood something.

[heydojo]

@abbradar this is the last time I am jumping in on this thread because of the nature of it and your response is actually a good question.
The variables are there to be changed if you want. Some are important. If they are deleted accidentally because someone thought that logging in as pid 1 and deleting things they do not understand would be fun then a person who does such a thing probably won't stop at deleting efi variables by accident and there is nothing anyone can do for that person. They stand to destroy their entire operating system on their own anyway, if they do not learn the error of their ways.

The reason to hard reset or read the manual for the machine or board is purely to find out if the machine has an efi reset. Not if that reset restores the variables. But it should.
The issue is that some vendors did not provide a reset method. It is just unfortunate for the very small number of people who bought hardware which claimed efi support but did not follow the spec and add a hard reset to their efi implementation.

I was a very early adopter of efi on the desktop (it has existed in servers way before) the machine I built for personal use at the time, I actually deliberately chose an Intel main board to base the system from not only for quality and reliability reasons but because it was one of the first commercially available desktop boards advertising efi.
I read the efi spec at the time. I also worked as a hardware engineer the last seven years.

So I am saying this is a non-issue.

[abbradar]

@heydojo Thanks for your detailed answer! Interesting -- indeed, this way one can find out some level of conformance to the standard.

I still respectfully disagree with your views on PID 1 and safety nets around it, but indeed let's not reiterate now (though I love a good dispute ~_^). Thanks again!

[copumpkin]

For more information on the topic: https://twitter.com/mjg59/status/693494314941288448

Led to this:
https://gist.github.com/mjg59/8d9d494da56fbe6d8992

[Profpatsch]

triage: I guess this can be closed?

[Ekleog]

@Profpatsch (from triage too) On a (18.03) machine efivarfs appears to still be mounted read-write, so I'd guess this isn't solved yet? Unless the gist posted by @copumpkin was actually a commit to the linux kernel, but I can't find either 3f5e3bdb or “Block most UEFI” in my local clone.

So I'd say this is still an ongoing issue, that has seen rough consensus in favor of making efivarfs read-only (to which I adhere)?

[dezgeg]

The kernel commit (referred above but in a different form) that fixed this was https://github.com/torvalds/linux/commit/ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879. So no action should be needed.