On February 1, 2016 11:57:01 AM EST, Jayesh Badwaik 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, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote:

On Mon, 01 Feb 2016 22:27:01 +0530 Jayesh Badwaik 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/

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

2016-02-01 23:29 GMT+01:00 Leonid Isaev :

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.

On 1 February 2016 at 23:29, Leonid Isaev 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​

On Mon, 1 Feb 2016 19:35:35 +0000 Tomasz Kramkowski 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 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.