[arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Hi, I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions. -- Cheers Jayesh Badwaik [1] https://wiki.archlinux.org/index.php/ Unified_Extensible_Firmware_Interface#Mount_efivarfs
On February 1, 2016 11:57:01 AM EST, Jayesh Badwaik <archlinux@jayeshbadwaik.in> wrote:
Hi,
I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions.
Well, that's why it's a wiki. Make an account, then go ahead and make that change. --Sean
On Mon, 01 Feb 2016 22:27:01 +0530 Jayesh Badwaik <archlinux@jayeshbadwaik.in> wrote:
Hi,
I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions.
The "dangers" are only if you do something dumb and your firmware is equally dumb. Even then, hopefully the kernel will take care of it. https://gist.github.com/mjg59/8d9d494da56fbe6d8992
On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote:
On Mon, 01 Feb 2016 22:27:01 +0530 Jayesh Badwaik <archlinux@jayeshbadwaik.in> wrote:
Hi,
I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions.
The "dangers" are only if you do something dumb and your firmware is equally dumb. Even then, hopefully the kernel will take care of it. https://gist.github.com/mjg59/8d9d494da56fbe6d8992
Since when does "do something dumb" and "potentially hard brick your motherboard" become synonymous when speaking in terms of computers? There's doing something dumb (by accident or otherwise) and then there's bricking your motherboard, people make accidents all the time but since modern day computers are quite nice and rugged, the only losses are data losses. I might shed a few tears over the loss of some not-backed up data, but I would be quite a bit more pissed off if I lost a valuable and expensive piece of hardware (granted, it would have to have a misconfigured and shitty EFI, but since when is "being misconfigured and shitty" a rare occurance?). The newbies this change is aimed for are exactly the sorts of people who might unwittingly rm -rf /. -- Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/
Am 01.02.2016 um 20:35 schrieb Tomasz Kramkowski:
The newbies this change is aimed for are exactly the sorts of people who might unwittingly rm -rf /.
Arch Linux is not aimed at newbies. There's been lots of panic over this issue, yet it took several years of UEFI being in the field for someone to actually trigger it. I guess it will be fixed in the kernel very soon. Until then we can calm down and start panicking - every local privilege escalation bug is worse than this stuff.
Tomasz Kramkowski wrote:
Since when does "do something dumb" and "potentially hard brick your motherboard" become synonymous when speaking in terms of computers?
There's doing something dumb (by accident or otherwise) and then there's bricking your motherboard, people make accidents all the time but since modern day computers are quite nice and rugged, the only losses are data losses.
You would think that a modern day machine is nice and rugged, but with EFI/UEFI, it isn't. There are way too many moving gears involved. The preboot environment has one primary task: find a bootable medium and boot it. Ideally, you should be able to configure it to tell it which medium to boot from. In the absence of a bootable medium, it should throw an error. Simple! This is how things worked before EFI. Sure, getting an OS to load was a magic trick in the early days ("pulling oneself up by one's bootstraps"), but today it is a finely honed procedure. There is nothing broken with this procedure. (After all, it boots!) Enter EFI and UEFI. From my (somewhat limited) experience with EFI, it seems like whoever designed it attempted to solve some fringe problem while creating 5 more problems in its place. Why do OSes need to modify the boot order entries? Why do some motherboards refuse to fallback to legacy BIOS? To make things worse, many hardware implementations are buggy and cannot be fixed (because there are already thousands/millions of units in production). So, if you want a modern day computer to be rugged: * Use legacy BIOS. There is nothing wrong with it. * Mount efivars (and related stuff) as ro by default. I read the systemd bug [0], but I still don't understand why so many tools need to write to it. How often do you need to change motherboard parameters after you get an OS set up? At that point, POST should be "find a device and boot it".
I might shed a few tears over the loss of some not-backed up data, but I would be quite a bit more pissed off if I lost a valuable and expensive piece of hardware (granted, it would have to have a misconfigured and shitty EFI, but since when is "being misconfigured and shitty" a rare occurance?).
I wish I could answer the philosophical question of whether rm should be able to brick hardware. I suggest someone mail Brian Kernighan, Robert Pike, or Ken Thompson. I would be really curious to hear what they think about this efivars thing. --Kyle [0]: https://github.com/systemd/systemd/issues/2402
On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
Tomasz Kramkowski wrote:
Since when does "do something dumb" and "potentially hard brick your motherboard" become synonymous when speaking in terms of computers?
There's doing something dumb (by accident or otherwise) and then there's bricking your motherboard, people make accidents all the time but since modern day computers are quite nice and rugged, the only losses are data losses.
* Use legacy BIOS. There is nothing wrong with it.
Exactly, I really don't understand this interest to UEFI (and don't mention secureboot). Also, how can you brick a machine by simply zeroing the harddrive? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
2016-02-01 23:29 GMT+01:00 Leonid Isaev <leonid.isaev@jila.colorado.edu>:
On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
Tomasz Kramkowski wrote: * Use legacy BIOS. There is nothing wrong with it. Exactly, I really don't understand this interest to UEFI (and don't mention secureboot).
Many new (OEM) machines do not support legacy BIOS.
Sebastiaan Lokhorst wrote:
2016-02-01 23:29 GMT+01:00 Leonid Isaev <leonid.isaev@jila.colorado.edu>:
On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
Tomasz Kramkowski wrote: * Use legacy BIOS. There is nothing wrong with it. Exactly, I really don't understand this interest to UEFI (and don't mention secureboot).
Many new (OEM) machines do not support legacy BIOS.
And this is what is so obnoxious/stupid about the whole situation. In their infinite wisdom, hardware manufacturers are writing broken implementations of an over-engineered system with no way to fallback to the tried/true system that has been around for decades. And when problems are discovered, it is too late. The systems are in production, and it is much easier to blame the consumer for uninstalling Windows than to admit there are millions of buggy boards in the wild. I really hope some sanity will return to the world of pre-boot. --Kyle
On 1 February 2016 at 23:29, Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
Also, how can you brick a machine by simply zeroing the harddrive?
You can't (well, someone can probably think of a contrived situation where you could, there's always someone, but generally speaking). The problem is with removing certain UEFI variables in buggy UEFI implementations (which are all too common). But in this case (with buggy UEFI implementation) a simple rm -rf of the wrong directory can brick your motherboard. -- Maarten
Maarten de Vries wrote:
On 1 February 2016 at 23:29, Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
Also, how can you brick a machine by simply zeroing the harddrive?
You can't (well, someone can probably think of a contrived situation where you could, there's always someone, but generally speaking). The problem is with removing certain UEFI variables in buggy UEFI implementations (which are all too common). But in this case (with buggy UEFI implementation) a simple rm -rf of the wrong directory can brick your motherboard.
-- Maarten
Interesting sidenote: In Android, all the system-level stuff is segregated to /system, which is mounted as ro by default. This is just another layer of security. --Kyle
On Mon, 1 Feb 2016 19:35:35 +0000 Tomasz Kramkowski <tk@the-tk.com> wrote:
On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote:
On Mon, 01 Feb 2016 22:27:01 +0530 Jayesh Badwaik <archlinux@jayeshbadwaik.in> wrote:
Hi,
I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions.
The "dangers" are only if you do something dumb and your firmware is equally dumb. Even then, hopefully the kernel will take care of it. https://gist.github.com/mjg59/8d9d494da56fbe6d8992
Since when does "do something dumb" and "potentially hard brick your motherboard" become synonymous when speaking in terms of computers?
I never said it shouldn't be dealt with, I'm just saying all of the coverage is really overblown. It's a very obscure set of circumstances that leads to this, and it appears will be handled in the kernel. Let's move on now.
participants (9)
-
Doug Newgard
-
Jayesh Badwaik
-
Kyle Terrien
-
Leonid Isaev
-
Maarten de Vries
-
Sean Greenslade
-
Sebastiaan Lokhorst
-
Thomas Bächler
-
Tomasz Kramkowski