31–40 of 180 posts
Why not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."
Why not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."
Earlier quoted context omitted.
The standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which feels even more fragile and confusing if you decide to wipe a hard drive to put a new OS on it unless you do everything just right.
How long before someone realises that grub could also be made part of systemd... cringes
Earlier quoted context omitted.
The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
Okay, I read the standard and you're right, they are supposed to install to a vendor specific location, so my apologies. Boot's an additional place you can put it, but not the regular place. As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which f…
You're goddamn right it is. Matthew Garrett [0] used to do UEFI stuff for -IIRC- RedHat. He has MANY blog posts about fucked-up parts of the spec, and horrifyingly fucked-up implementations of the same. Sadly, it looks like most (if not all) of his posts are now tagged "advogato, fedora", so I can't point you specifically to the UEFI gore posts.
These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…
Sometimes people run rm -rf / just for fun before reformatting a system, just to see what happens. Given that its purpose in life is to delete files, it stands to reason that running this command on a system which contains no important data is OK. A default configuration which makes this command destroy hardware is not reasonable.
It also supports --one-file-system, which would prevent this and a host of other problems as well. That said, I don't really see a problem with Lennart's response. It's basically, "we should take steps to make this hard to do, but root is capable of doing anything, so don't expect it to be foolproof."
1: https://www.gnu.org/software/coreutils/manual/html_node/rm-i...
2: https://www.gnu.org/software/coreutils/manual/html_node/Trea...
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. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…
"let's make everything a filesystem so it's dead easy to hang yourself from userland tools"
Anyone can "rm -rf" anything, that doesn't mean that they should.
And that's the sort of thing that could easily sneak into the `curl http://some/url | sudo bash`-style of installs that are popular these days.
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. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…
If you mount efivarsfs read-only, efibootmgr can't make your system bootable. So at a minimum, you can't just remount the filesystem read-only; you need distribution integration so efibootmgr can still write to it. There's no point in mounting efivarsfs read-only; you might as well not mount it at all.
You'd think that efibootmgr would have a "--temporarily-remount-efivarsfs-readwrite" flag to handle that very thing, given hardware vendors' long history of getting UEFI dangerously wrong. :/
Earlier quoted context omitted.
"let's make everything a filesystem so it's dead easy to hang yourself from userland tools"
Let's make everything a filesystem... so that they are easy to access and modify. Anyone can "rm -rf" anything, that doesn't mean that they should.