Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

github.com

Post reply on HN
Print view View original

171–180 of 180 posts

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#171

Post by icebraining »

snuxoll wrote: post #105
Silhouette wrote: post #44

Earlier quoted context omitted.

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. I tend to think the Linux on the desktop thing is a bit of a diversion, but this issue and Poettering's response certainly lend weight to the concerns many have raised about systemd. What happened to defence in depth? Even if your users…

Did Lennart have anything to do with the actual efivars implementation in the kernel? If so, then yeah, shame on him by all means. I agree it's a broken abstraction, but it's what the kernel developers decided on (and they sure like making system configuration available with filesystems, see sysfs and procfs). Ultimately access is needed to even configure the bootloader, and right now that means it needs to be mounte…

By the way, here's the author of the kernel module in question, talking about this issue:

https://twitter.com/mjg59/status/693494314941288448

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#172

Post by yrro »

snuxoll wrote: post #156
mikeash wrote: post #141

Earlier quoted context omitted.

Regarding your edit, exactly. The issue could be considered a security issue, but this fix is not a security fix. A security fix would be something like only allowing touching EFI during startup and then somehow securely and permanently disabling that ability until the next reboot, or a physical write-protect switch on the computer. Or EFI firmware not being so stupid, but we know that's not going to happen.

Maybe if there was some awful Windows virus that nuked boards with bad implementations they would fix their crap.

Bingo. You're only a call to SetFirmwareEnvironmentVariable away from having your Windows system hosed.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#173

Post by [deleted] »

SFjulie1 wrote: post #164
_qc3o wrote: post #58

Earlier quoted context omitted.

With fuse you certainly can.

Yeah. Never coded a driver did you? It is as smart as saying that by using a hammer heavy enough you can make a cube fit in a triangle. It is possible, but defeating the purpose of consistent API.

[deleted]

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#175

Post by Sophira »

clinta wrote: post #81
deathanatos wrote: post #64

Earlier quoted context omitted.

Not only is root root, and should be permitted to access and modify the system as desired, it seems to me that the root of this problem is that motherboard manufacturers are shipping faulty boards. I shouldn't be able to brick my motherboard from my operating system, and that I can is a bug. You're telling me there isn't so much as a factory reset on these boards? Perhaps systemd could shield users from their motherb…

We've been living in a world where you couldn't brick the firmware from the OS for a long time, and it's been terrible. I'm perfectly happy to take the risk of being able to brick a board from the OS if it means I never again have to try boot to a dos disk and run a proprietary exe to update the BIOS. Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can…

The point isn't that it can be bricked; it's that it's possible to brick it via an "rm". Or heck, doing anything hardware-related via an 'rm'.

The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you remove a socket - even though all of these things are interfaces to the kernel in one form or another. Removing these files only removes your ability to access that interface.

Simiarly with files in /proc - which, like /sys, is directly exported by the kernel. In many cases the kernel refuses to even allow you to unlink the 'files' in /proc, even when it might make sense. (For example, you can't kill a process by 'rm'ing anything in the relevant /proc directory.) Instead, you update the configuration values that the files in /proc represent by echoing into their contents, where applicable.

The case with the efivars 'file' actually causing the kernel to take action when it's removed is what's at issue here. The fact that it happens to brick some computers is particularly unfortunate, but does a good job with showing the problem here. This isn't what the "everything is a file" philosophy is about.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#176

Post by snuxoll »

icebraining wrote: post #171
snuxoll wrote: post #105

Earlier quoted context omitted.

Did Lennart have anything to do with the actual efivars implementation in the kernel? If so, then yeah, shame on him by all means. I agree it's a broken abstraction, but it's what the kernel developers decided on (and they sure like making system configuration available with filesystems, see sysfs and procfs). Ultimately access is needed to even configure the bootloader, and right now that means it needs to be mounte…

By the way, here's the author of the kernel module in question, talking about this issue: https://twitter.com/mjg59/status/693494314941288448

I'm really glad he's speaking out on the issue, Matt is a smart guy (I used to talk with him frequently on IRC) and it's sad to see many of the same people trying to act like they know better than him in that twitter thread. There's no easy fix to this issue, and regardless of whether an rm -rf / can hose your system there's bigger issues at stake with malicious actors that a stupid bandaid like that won't fix.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#177

Post by groovy2shoes »

krylon wrote: post #143
pdkl95 wrote: post #135

Earlier quoted context omitted.

> I have not experienced any of these problems myself That's the problem any time[1] a system is designed around ideological purity. Someone invents something clever that works most of the time for most people (with varying definitions of "most"), so they try to apply it everywhere. As no idea can account for everything[2], this sooner or later the inflexibility of the theory meets the variation of realty and some ty…

Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order. The problems systemd tried to address are real, and some of the ideas behind it are appealing. But the way it attempts to replace several important pieces of the system at once, and the way it is being forced on people in a "eat it or leave it"-style feels uncomfortable. Part of what made Unix what it is…

Out of curiosity, what do you consider to be real problems that systemd is trying to address? (Honest question).

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#178

Post by clinta »

Sophira wrote: post #175
clinta wrote: post #81

Earlier quoted context omitted.

We've been living in a world where you couldn't brick the firmware from the OS for a long time, and it's been terrible. I'm perfectly happy to take the risk of being able to brick a board from the OS if it means I never again have to try boot to a dos disk and run a proprietary exe to update the BIOS. Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can…

The point isn't that it can be bricked; it's that it's possible to brick it via an "rm". Or heck, doing anything hardware-related via an 'rm'. The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you re…

I was not defending SystemD, I was defending the hardware manufacturers against the accusation that they're "shipping faulty boards".

I think SystemD is in the wrong here. Operating Systems should be protecting users from bricking their hardware.

Harware manufacturers should not be shipping hardware that's nearly impossible to brick, because it results in hardware that is nearly impossible to update.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#179

Post by snuxoll »

intelfx wrote: post #167
snuxoll wrote: post #158

Earlier quoted context omitted.

A traditional BIOS or UEFI running in CSM requires an MBR formatted disk since the bootloader must be started from the first 512 bytes on disk. I have to boot ESXi on my ProLiant ML10 off a flash drive because my 3TB disk would become a 2TB disk otherwise.

Did you hear about "hybrid MBR"?

Hybrid MBR is an extremely fragile and hackish technique to make crappy old firmware boot larger disks. In general I want my whole 3TB drive allocated to VM storage instead of partitioning it up so ESXi has somewhere to live, so just running that off an easily replaceable USB key is a lot simpler to maintain.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#180

Post by krylon »

groovy2shoes wrote: post #177
krylon wrote: post #143

Earlier quoted context omitted.

Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order. The problems systemd tried to address are real, and some of the ideas behind it are appealing. But the way it attempts to replace several important pieces of the system at once, and the way it is being forced on people in a "eat it or leave it"-style feels uncomfortable. Part of what made Unix what it is…

Out of curiosity, what do you consider to be real problems that systemd is trying to address? (Honest question).

For one thing, a method service management that does not just fire off commands but monitors services and restarts them if they fail. Also, doing this with an idea of dependencies of services.

Event-based service management is interesting, too, e.g. shutting down a network service when the machine is disconnected from the network and restarts them when a connection becomes available again (think NTP, DHCP clients).

Once you have an idea of how services depend on each other, you get the ability to start services in parallel for free (whether that is so useful or even a good idea is another question).

Given the fact that systemd is hardly the first attempt to solve these issues (think SMF on Solaris, launchd on OS X, or the couple of attempts on GNU/Linux), I think a lot of people have felt the itch to improve on the classical SysV init.

Post reply on HN