EFI Security Improvements & More For Linux 4.6

[bug77]

But you're not "Erasing a partition", you're removing a file system; distinct difference there.

Well, that's exactly the issue. Why is rm removing a file system?
Because if I check what rm does I get:

rm --help
Usage: rm [OPTION]... FILE...
Remove (unlink) the FILE(s).

So if it's not supposed to remove a file system, can we, please not put file systems where rm can delete them?

[unixfan2001]

...or just have enough history of risk-averseness to have a BIOS-based desktop and an ARM palmtop with unbrickable booting while you wait for people to come to their senses a bit.

No one is going to go back to old style BIOS, so I'm afraid you'll have to wait indefinitely.
There are good reasons for the existence of (U)EFI.

[unixfan2001]

But you're not "Erasing a partition", you're removing a file system; distinct difference there.

This is more comparable to driving down a mountain road, which doesn't need rails due to a reduced speed limit. If people want to drive recklessly, blaming a the death on the lack of rails seems silly. You can screw up you computer hardware in various ways by running commands as su without knowing the consequences.

I would argue a better solution would be making the rm flag "one-file-system" default, or at least when no-preserve-root is used.

As someone who had an accident barely more than a month ago, I'd like to ask you why the heck you think a speed limit or "common sense" would replace sane security precautions?
I crashed my car at 15 mp/h, due to a slippery road and frozen wreckage puncturing one of my tires.

For all I care, that mountain road could have a speed limit of 3 mp/h. If it's dangerous, railings are the only sane solution.

[Ericg]

Well, that's exactly the issue. Why is rm removing a file system?
Because if I check what rm does I get:

rm --help
Usage: rm [OPTION]... FILE...
Remove (unlink) the FILE(s).

So if it's not supposed to remove a file system, can we, please not put file systems where rm can delete them?

Rm doesn't remove the filesystem itself, it didn't go through and delete the filesystem headers or anything like that. Linux mounts the firmware variables under /sys/, UNIX says that everything is a file. Rm works on files, therefore rm can delete the 'files' that represent the UEFI variables. The problem is that some motherboards do not have backups of those variables, so when rm deletes them.. That's it. They're gone, and your computer can't boot anymore.

Other motherboards are designed to have immutable copies of those files. For those motherboards, they just swap in the backups for the deleted files and continue booting.

[Mystro256]

Well, that's exactly the issue. Why is rm removing a file system?
Because if I check what rm does I get:

rm --help
Usage: rm [OPTION]... FILE...
Remove (unlink) the FILE(s).

So if it's not supposed to remove a file system, can we, please not put file systems where rm can delete them?

This is why I argue that --one-file-system should be default.

[ssokolow]

No one is going to go back to old style BIOS, so I'm afraid you'll have to wait indefinitely.
There are good reasons for the existence of (U)EFI.

Actually, I was thinking more along the lines of waiting until I see Coreboot gain support for something suitable.

There's absolutely no need for my firmware to have more code than my kernel... especially when hardware people are so infamously bad at software QA.

[starshipeleven]

There are good reasons for the existence of (U)EFI.

List them, I want to laugh. There are good reasons to drop BIOS, that's true. But to use UEFI?

UEFI causes a RIDICOLOUS amount of retarded issues in the field, without adding anything particularly interesting to the table that BIOS wasn't already doing fine. Ah yes, the "security" stuff. Yeah, that's great. Nice. Awesome. If the average board firmware wasn't buggy as hell already I would actually care about that.

Mostly because the devs of the board firmwares suck hard.

I've lost count on how many POS laptops and convertibles cannot boot reliably in BIOS-mode or off a usb drive (or insist in booting off the network if you turn on completely unrelated settings). Even goddamn Windows usb sticks are hit-and-miss on them.

Or Gigabyte's dual-bios in boards. That's just great, if one dies, the board should switch to the other and you should be fine.
In real life this may or may not happen at all (I've had to physically short pins of the EEPROM chip following guides I found in forums to get this to happen quite a few times), and if it happens it usually has an ancient firmware onboard so you risk not booting anyway because the board can't use the processor.

Or the current issue. Like not having a read-only default settings thing that is restored if somehow the current one gets wiped by the OS.

Seriously, they could have implemented something like say a rEFInd-like boot manager that totally rocks, a small NAND space where I can keep bootloaders instead of placing them in a hard drive (yeah, who cares of multi-Hdd dual boot and RAID users anyway).

Or a simple toggle read-only/writable for the board firmware. I think it's currently a novelty in some high-end server boards or something. High tech man. Smells like premium.

All they do is pimp the configuration interface and fail to add decent readouts for ECC ram settings (like say show if the fucking ECC is enabled or not), VT-D/IOMMU and similar stuff. And I'm talking of worstation boards, not "gaming" shit with leds, nor low-end boards (that still get pimped).

And please note that I'm using rEFInd on all my UEFI systems, I'm not some kind of unwashed luddite.