Remounting efivars as ro to safeguard hardware. Best practice?

graysky · 2016-01-26 20:12:48

After reading this post wherein it seems that the OP bricked his motherboard rendering it useless (read carefully -- MOTHERBOARD not just a particular installation -- and pondering Lennart Poettering's reply to the issue, am I wondering if adding the following line to one's /etc/fstab is or should be considered a post-install best practice? Aside from the obvious need to manually remount it should users wish to write to the $esp, are there other side effects that would argue against it?

efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0

Silkworm205 · 2016-01-26 20:49:02

It could make a good commented-by-default addition to genfstab. As far as I'm aware, bootloaders will throw an error if the directory is read only rather than fail spectacularly. I can't think of many other legitimate programs that'd want write access.

graysky · 2016-01-26 20:50:18

Silkworm205 wrote:

It could make a good commented-by-default addition to genfstab. As far as I'm aware, bootloaders will throw an error if the directory is read only rather than fail spectacularly. I can't think of many other legitimate programs that'd want write access.

I was thinking the same... can you confirm that for example install grub with this setup as ro does in fact throw an error?

Trilby · 2016-01-26 20:58:31

I'm still curious how big of a problem this is. Not that we should ignore a catestrophic problem even if it will only affect a few very specific models of hardware - but the response should be measured by the potential impact. If susceptibility is the norm for EFI firmware, then I'd say there should be some precautionary default. But if this susceptibility is essentially a rare flaw in specific machines, it might be best noted somewhere on a machine-specific page of the wiki.

Silkworm205 · 2016-01-26 21:09:33

graysky wrote:

I was thinking the same... can you confirm that for example install grub with this setup as ro does in fact throw an error?

I don't use UEFI so I can't say myself. And I'm not willing to risk any of my machines to find out. If any old machines come in where I work for decommissioning and support UEFI, I'll try them.

laloch · 2016-01-26 21:20:22

Trilby wrote:

I'm still curious how big of a problem this is. Not that we should ignore a catestrophic problem even if it will only affect a few very specific models of hardware - but the response should be measured by the potential impact. If susceptibility is the norm for EFI firmware, then I'd say there should be some precautionary default. But if this susceptibility is essentially a rare flaw in specific machines, it might be best noted somewhere on a machine-specific page of the wiki.

Even if the victim would be so lucky to own a board with firmware which can recover from the loss of the EFI variables, she would certainly lose all boot options and thus would not be able to boot any of the installed OSes. See the UEFI spec. v2.5, Chapter 3.3 - Globally Defined Variables for the list of the affected configuration items. The variables with an RT attribute are accessible from an operating system by design even on non-buggy platforms.

respiranto · 2016-01-26 21:24:12

Silkworm205 wrote:

graysky wrote:
I was thinking the same... can you confirm that for example install grub with this setup as ro does in fact throw an error?
I don't use UEFI so I can't say myself. And I'm not willing to risk any of my machines to find out. If any old machines come in where I work for decommissioning and support UEFI, I'll try them.

I do not see how this should be a risk.

# mount -o remount,ro /sys/firmware/efi/efivarfs
# grub-install --efi-directory=/boot --bootloader-id=GRUB --recheck
Installing for x86_64-efi platform.
efibootmgr: Boot entry 0001 not found
efibootmgr: Could not delete boot variable: Read-only file system
** Warning ** : Boot0001 has same label GRUB
efibootmgr: Could not set variable Boot0002: Read-only file system
efibootmgr: Could not prepare boot variable: Read-only file system
Installation finished. No error reported.

EDIT:
I personally do not think, that the efivarfs should be recommended to be mounted as ro by default, as long as this issue does not affect a sufficiently large amount of hardware.
However, it is certainly a good idea to add a note on this not only in hardware specific pages, but also in the Beginner's Guide and possibly others, since I believe the reason for looking on a hardware specific page is often a problem with such, which in this case is fatal.

laloch wrote:

Even if the victim would be so lucky to own a board with firmware which can recover from the loss of the EFI variables, she would certainly lose all boot options and thus would not be able to boot any of the installed OSes.

If running, `rm -rf --no-preserve-root', not being able to boot any operationg system from the disk should certainly not be something to be unprepared for.

Last edited by respiranto (2016-01-26 21:36:48)

mich41 · 2016-01-26 21:41:50

Trilby wrote:

I'm still curious how big of a problem this is.

So what are you waiting for? It takes just one command to find out

Or seriously, if I had UEFI boxes, I'd probably examine their efivars, especially any nonstandard ones. If the names or contents suggest that they contain low level firmware settings or, even worse, the default firmware settings, then I'd assume that deleting or modifying them is a very bad idea indeed.

Last edited by mich41 (2016-01-26 21:43:40)

laloch · 2016-01-26 21:59:18

respiranto wrote:

laloch wrote:
Even if the victim would be so lucky to own a board with firmware which can recover from the loss of the EFI variables, she would certainly lose all boot options and thus would not be able to boot any of the installed OSes.
If running, `rm -rf --no-preserve-root', not being able to boot any operationg system from the disk should certainly not be something to be unprepared for.

I don't follow. Why should I be prepared for rm -rf / screwing a <pick_your_favorite_OS> installation in another partition on another disk?

respiranto · 2016-01-26 22:27:55

laloch wrote:

I don't follow. Why should I be prepared for rm -rf / screwing a <pick_your_favorite_OS> installation in another partition on another disk?

Because there is no reason to do this except for a little risk and self-amusement.
Furthermore, it does not affect any other partition, except when it is mounted. It only affects the efivarfs, since it is mounted, which certainly is intended behaviour.

Anyways, if at all, one should never do this without a live CD within arms reach.
What if GRUB was the only boot option and the grub.cfg was on a mounted partition?
Or even worse, the grubx64.efi?
Which would probably imply the loss of any possibly existing EFI-executables anyway.

TheSaint · 2016-01-27 13:31:00

I suppose that could takee a bit of hacking on rm itself. In the particular case that has this formula. So anything like

# rm /  ### note no trailing anything after the slash

it should turn into -i (interactive mode).

graysky · 2016-01-27 17:27:51

When ever I needed to blow away a Linux install, I always did so from another environment on unmounted partition so I never ran into this. I opened this thread becuase I don't like the exhaust port of the deathstar begin exposed on my system... I have been running with the at ro mount without ill effects since I opened this thread. While I would never run the rm command on the live file system, I still think this could be seen as cheap insurance particularly if there is not a downside to doing it. Soliciting feedback on that was my major goal in opening this thread. Is that, in fact consensus? If so, let's add a blurb to the wiki and call it a day.

R00KIE · 2016-01-27 21:50:41

There is always the risk that if this is not common now it might become common (1), so at least a warning in a visible place in the wiki is most probably a good idea.

(1) Now that UEFI has pretty setup screens manufacturers might feel the need to let users change every setting from within windose, thus needing full access to the current configuration and/or defaults. What is baffling is that there is no sane way to at least get things to a working failsafe state.

graysky · 2016-01-27 22:05:47

R00KIE wrote:

What is baffling is that there is no sane way to at least get things to a working failsafe state.

+1

We never did hear back from the author of the thread I linked whose system got hosed per his/her user page (last post 14-Jan as I write this).

kazimir · 2016-01-30 16:52:32

He says he sent it to the manufacturer under warranty: https://bbs.archlinux.org/viewtopic.php … 3#p1599733

kazimir · 2016-01-30 17:05:15

respiranto wrote:

If running, `rm -rf --no-preserve-root', not being able to boot any operating system from the disk should certainly not be something to be unprepared for.

To the contrary, this is a violation of the principle of least astonishment, if I rm -rf / --no-preserve-root on one OS I expect this to have no effect on the other OSes on the same computer, not even talking about rendering hardware useless.

I wonder about some other cases, what about the case of a box running multiple virtualized OSes ? a chrooted mounted DD image ?

ayekat · 2016-02-01 06:57:54

Trilby wrote:

I'm still curious how big of a problem this is. Not that we should ignore a catestrophic problem even if it will only affect a few very specific models of hardware - but the response should be measured by the potential impact. If susceptibility is the norm for EFI firmware, then I'd say there should be some precautionary default. But if this susceptibility is essentially a rare flaw in specific machines, it might be best noted somewhere on a machine-specific page of the wiki.

I feel like it's not as isolated as we'd wish for, given the vast majority of EFI implementations that simply don't behave as expected in certain cases (and I wouldn't be surprised if they could thus all be bricked with a deletion of the efivars).

The concrete case: a friend of mine ran into the same issue a couple of weeks ago on his Thinkpad Edge¹. Ironically, he did think of ro/rw file systems, because he wanted to see at what point his NixOS installation would survive an `rm -rf /*`, given that the system's states seem to be stored read-only.

____
¹ I'll report back with the exact model once I know it.

Last edited by ayekat (2016-02-01 07:04:32)

TheSaint · 2016-02-01 14:24:24

graysky wrote:

When ever I needed to blow away a Linux install

I'm my case I used

# dd if/dev/null of=/dev/sdX bs=1M count=1 # or a bit more counts

Anyway there's a flaw in the (U)EFI and BIOS implementation. That's needed to be corrected. At certain point any OS can blow the efivars, because are exposed to the OS. But there aren't counteractions to recover from a blank NVRAM, within the BIOS firmware.
We can put a warning into the wiki, until manufacturer will fix their BIOSes.
In few words, in reply to the title, the answer is it's not enough. The implementation maybe spoofed one day very soon.

Last edited by TheSaint (2016-02-02 07:41:22)

Scimmia · 2016-02-01 14:51:28

TheSaint wrote:

But there aren't counteractions to recover from a blank NVRAM, within the BIOS firmware.

BIOS doesn't use NVRAM like this at all.

Last edited by Scimmia (2016-02-01 15:07:28)

R00KIE · 2016-02-01 15:04:11

TheSaint wrote:

Anyway there's a flaw in the (U)EFI and BIOS implementation. That's needed to be corrected. At certain point any OS can blow the efivars, because are exposed to the OS. But there aren't counteractions to recover from a blank NVRAM, within the BIOS firmware.
We can put a warning into the wiki, until manufacturer will fix their BIOSes.

I wouldn't hold my breath waiting for that. The manufacturers will not take action until they are forced to, like when some new virus starts bricking motherboards left and right, and even then they will try to shift the blame somewhere else. It might also be that the spec requires this kind of access and in that case not much can be done. Do note that I am not familiar with the uefi spec so this is a guess, but it wouldn't surprise me much if this is the case.

graysky · 2016-02-01 20:27:47

OK... I think the consensus is that it is in fact a good idea to mention this on the wiki. Which page or pages are appropriate? Some thoughts:
https://wiki.archlinux.org/index.php/Be … stallation
https://wiki.archlinux.org/index.php/Ge … mendations

Option 1 would be stronger than 2 since it really only links 2. I don't feel like 2 is good since that page is already so large. Other ideas are welcome.

Head_on_a_Stick · 2016-02-01 20:30:56

@Alad has already added a section:
https://wiki.archlinux.org/index.php/Un … t_efivarfs

EDIT: @Alad, you rock!

Last edited by Head_on_a_Stick (2016-02-01 20:32:23)

Trilby · 2016-02-01 20:46:41

Does anyone know how this ro mounting of efivars compares to the kernel option "noefi" or to blacklisting the efivars module? It seems if one is paranoid, the latter options might be better as then the efivars don't need to be remounted ro as they are simply not mounted in the first place.

graysky · 2016-02-01 20:47:21

Head_on_a_Stick wrote:

@Alad has already added a section:
https://wiki.archlinux.org/index.php/Un … t_efivarfs
EDIT: @Alad, you rock!

Good content, but my fear is that it may receive poor coverage there. If in fact one can break hardware, my opinion is that the warning or at least a link to it should be on a more popular page like the BG. Perhaps under the EFI section therein or at the end. Guess I'll make the edit and let the discussion happen on the Talk page.

EDIT: https://wiki.archlinux.org/index.php?ti … did=418206

Last edited by graysky (2016-02-01 20:47:39)

Alad · 2016-02-01 20:50:02

At one point, the beginners' guide contained more warnings than actual instructions, so I'm fairly conservative on adding things there. Please see the discussion page if you disagree with this.

Arch Linux

#1 2016-01-26 20:12:48

Remounting efivars as ro to safeguard hardware. Best practice?

#2 2016-01-26 20:49:02

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#3 2016-01-26 20:50:18

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#4 2016-01-26 20:58:31

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#5 2016-01-26 21:09:33

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#6 2016-01-26 21:20:22

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#7 2016-01-26 21:24:12

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#8 2016-01-26 21:41:50

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#9 2016-01-26 21:59:18

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#10 2016-01-26 22:27:55

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#11 2016-01-27 13:31:00

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#12 2016-01-27 17:27:51

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#13 2016-01-27 21:50:41

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#14 2016-01-27 22:05:47

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#15 2016-01-30 16:52:32

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#16 2016-01-30 17:05:15

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#17 2016-02-01 06:57:54

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#18 2016-02-01 14:24:24

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#19 2016-02-01 14:51:28

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#20 2016-02-01 15:04:11

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#21 2016-02-01 20:27:47

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#22 2016-02-01 20:30:56

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#23 2016-02-01 20:46:41

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#24 2016-02-01 20:47:21

Re: Remounting efivars as ro to safeguard hardware. Best practice?

#25 2016-02-01 20:50:02

Re: Remounting efivars as ro to safeguard hardware. Best practice?

Board footer