Live data from Hacker News

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

github.com

161–170 of 180 posts

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

#161
post #72
post #68

Earlier quoted context omitted.

He says "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root." That looks like agreement that it needs something done to me. I took the followup comment to be a useful to on how to mitigate the problem until then.

Isn't it already only writeable by root? The request is to make it not even writeable by root without taking some additional action to make it writeable first. If I understand correctly, that bit you quote just describes the current situation.

I take the and in his reply to infer he agrees something additional should be done. Whether his ultimate response for how to do that is adequate is unknown, since he didn't really elaborate on exactly what he thinks should be done. It could be he meant that to signify agreement with the suggested course of action in addition to agreement that there's a problem to be fixed.

In any case, the only thing clear to me from his statements is that he agreed that there was a problem in need of attention, which makes the response here somewhat baffling to me (although not as baffling as it should be. It's fairly easy to see how a lot of the animosity comes from feeling about systemd in general and Lennart in particular, especially since some people state as much, as if that has any bearing on his response in this instance).

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

#162
post #42

Earlier quoted context omitted.

That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…

Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.

Yes. And all I see from Lennart is agreement and the statement of a few facts (some programs need access), which implies that a slightly more nuanced solution may be required. I fail to see how this reflects poorly on him.

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

#163

Earlier quoted context omitted.

Technically, denial of service is a security issue - I have modern servers that boot via UEFI (since GPT is required to support large disks), hopefully with less buggy implementations but if someone manages to get root on a server they could totally kill the hardware. Having to reinstall an OS because some script kiddie decided to `rm -rf --no-preserve-root /` your server bites, but actually bricking the system requi…

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.

More precisely, every EFI firmware not being so stupid. BTW, you will see that a "high quality UEFI BIOS" is part of my wishlist for an Intel/AMD branded laptop: https://www.reddit.com/r/hardware/comments/42cnbq/would_inte...

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

#164
post #58

Earlier quoted context omitted.

A file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.

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.

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

#165

Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that". It worked safely before, it should still be safe to do. (yes I know about --no-preserve-root)

> Unix has a long tradition of doing a `rm -rf /` before reinstalling a system.

Uh, what? Somebody was trolling you if they gave you that advice. In the days of NFS or AFS (God, I'm old) that could get you into serious trouble if it wandered into somewhere unprotected.

dd if=/dev/zero of=/dev/? Sure. Bog standard guaranteed erase of the disk. Doing that even once means that you're now in NSA territory to recover it.

rm -rf /? Never heard of that, ever.

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

#166
post #30

I can't understand why people argue about this. Just put some safety measures on it already. Or at least change the rm option to "--brick-my-motherboard"

1) systemd is the wrong place for the safety measures. rm is also the wrong place for the safety measures.

2) remounting a mounted FS is a non-trivial operation with lots of corner cases. What happens when another program is accessing that FS at the same time?

It's simple--the kernel needs to be fixed. Access to EFI should require special sequences to cause writes.

systemd folks aren't going to ask for it because Linus will simply piss and moan and close as WONTFIX/NOTABUG.

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

#167

Earlier quoted context omitted.

If I had a system that I booted in UEFI mode, I could tell you, but all of my hardware (even the ones running UEFI) boot OSs in BIOS mode. Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades. GRUB2 seems to use efibootmgr to write stuff to EFI, and efibootmgr appears to lack a "detect if efivarfs is mount…

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"?

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

#168

Earlier quoted context omitted.

> As an aside, goddamn is UEFI ugly. I was installing a graphics card once and broke my EFI setup. Not because of the graphics card, but because I apparently bumped the CMOS battery enough to wipe settings.

Uh... don't do that?

Sure, but historically something like that wouldn't render a system unable to boot an already installed operating system.

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

#169
post #150

Earlier quoted context omitted.

> It's entirely possible that Apple takes code or inspiration from the Linux software project, but I think it's better to say that OS X is Unix based. Apple can't take code from Linux as the code is GPL licensed. OSX is largely based on NeXT and BSD. Linux and OSX are both POSIXish though.

OS X had been UNIX certified, at some point, though. Don't know if that is still true

[deleted]

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

#170
post #150

Earlier quoted context omitted.

> It's entirely possible that Apple takes code or inspiration from the Linux software project, but I think it's better to say that OS X is Unix based. Apple can't take code from Linux as the code is GPL licensed. OSX is largely based on NeXT and BSD. Linux and OSX are both POSIXish though.

OS X had been UNIX certified, at some point, though. Don't know if that is still true

It is. Various optional things from POSIX are missing though (https://github.com/uxcn/yafd/blob/master/src/c/pthread-dw.h).
Post reply on HN