The UEFI SecureBoot Saga For Linux Continues

[Qaridarium]

german wikipedia talk about efi as a security risk:

"EFI is a developer of core boat, according to safety-critical application environments - such as in banks - as a potential security risk because there would be some of the implemented network stack, the theoretical possibility of data without being noticed by the operating system to an arbitrary address to send. Our own network stack for TCP / IP, which runs "below" the operating system directly and independently on the motherboard allows you to manipulate the system to infect or monitor, without being able to control it, for example, from Windows or limit. Also DRM purposes EFI could be used to as the I / O data stream on digital watermark to monitor out. For these reasons, some users are more likely to advocate an open source system such as coreboot (formerly LinuxBIOS). [18] [21] [22]"

https://de.wikipedia.org/wiki/UEFI#Kritik

[Kano]

You can attack every system, but be sure the most common way is to use the mbr up to now for those things. the first virus that used the mbr must be as old as dos. It does not matter if you use coreboot or whatever, if you want to attack a system you find a way - and if you need to write a new bios/uefi then you do so. As soon as flashrom works and your enemy is root on your system he can attack the bios directly as well, no matter if it is internally uefi or not. You can simply add an option rom with your code that will be executed on boot. Of course you dont know that as you never modified a bios, but i did - i added/replaced vga rom, raid rom, pxe, plop...

[Qaridarium]

You can attack every system, but be sure the most common way is to use the mbr up to now for those things. the first virus that used the mbr must be as old as dos. It does not matter if you use coreboot or whatever, if you want to attack a system you find a way - and if you need to write a new bios/uefi then you do so. As soon as flashrom works and your enemy is root on your system he can attack the bios directly as well, no matter if it is internally uefi or not. You can simply add an option rom with your code that will be executed on boot. Of course you dont know that as you never modified a bios, but i did - i added/replaced vga rom, raid rom, pxe, plop...

because of this you use virtualizations with full hardware emulation then the enemy THINK he attacking something but he only do it in the emulation and this set the emulation to "hold" because of the Intrusion Detection System.

[Kano]

That's pure nonsense. And if you don't know: you can use Coreboot with UEFI payload.

[oliver]

The little problem that a lot of people are forgetting, especially those of us who would boycott secureboot, is that all vendors will put it in their systems and why should they even care about the option to be able to disable it? "All our users are windos users anyway, who cares?" And server users are actually 'happy' with this.

This is just a tool for MS to increase their grasp on the user.

If this would even work remotely, a separate instance unrelated to M$ will need to be in charge of signing. But even better, would be the option to put your key into the bios yourself. Ubuntu, Redhad can buy their key for 'joe user'. Everybody else can just use their own key and put it in the bios. Of course the bios would have to support putting the key into an area that cannot be written to from the OS, ever. Hell, require 12V programming voltage that can only be applied by the use of a jumper. Annoying and difficult? Absolutly, but it would be a reasonable safe option.

Of course this would only ever come if required by the EU law. As USA law will be adapted to suit whatever M$ wants and just bends over for them anyhow.


Finally, hopefully this will spurt coreboot development. If a board is properly supported by coreboot, just remove the 'secureboot hell' and put coreboot in and be happy.

[Kano]

I still don't get your point, ms definitely stated that on x86 platform the uefi setup MUST provide an option to disable secure boot. Only on ARM there may NOT be an option to disable it. That makes it non trivial if you dont want to desolder the eeprom of course, but maybe you find a spi interface to use. UEFI is not graved into stone, if you want to modify it, you find a way.

[123456789]

Why cant we just ensure that Linux boots on an SecureBoot enabled box
and then, do what ever we want, like loading closed source modules, installing a
self-compiled kernel ...
Essentially guaranteeing the freedom of the user to do what ever he wants.

[ulenrich]

Please, enlighten me about features of secure boot:

- Just to prevent some rootkit to be installed from a running MsWin?
This you could be prevented, even if they give away secure-boot keys: Uefi just has to announce the owner of the starting software from key before booting!

- Prevent criminal hardware access?
This for you have to encrypt all bits on the drive.

- Prevent users in a commercial environment from tampering?
They have to encrypt all bits on the drive,
and they have to keep secret admin-root passwords from the users.
And they have to disable alternative starting points.

I think all is possible. And I think Red Hat and SUSE do want to provide services to their customers for all of it ...

[oliver]

I still don't get your point, ms definitely stated that on x86 platform the uefi setup MUST provide an option to disable secure boot. Only on ARM there may NOT be an option to disable it. That makes it non trivial if you dont want to desolder the eeprom of course, but maybe you find a spi interface to use. UEFI is not graved into stone, if you want to modify it, you find a way.

Are you sure it MUST provide an option to disable it? I believe it was 'does not have to be enabled. In any case, this will be just the first step.

[Zapitron]

It's not whether anyone wants to or not. It's as Alex said: for systems where disabling secure boot is not an option (because disabling it isn't implemented properly or not at all or the user is too stupid to disable it), it will be impossible to get a signed bootloader / signed kernel for a system with the proprietary modules. That's because the proprietary modules essentially do "user-space modesetting", and most of the real low-level logic is done through a user-space library. Allowing this kind of low-level access into the hardware from userspace would not be permitted by the secure boot folks; they wouldn't allow you to sign a bootloader and kernel that has this kind of gaping security hole, where anyone with root could just write to an arbitrary area in memory.

A $99 service is going to audit the whole kernel? My bet is that whoever is taking that $99 probably doesn't even know what Linux is, much less has the time or inclination to think about what proprietary driver modules are. Whatever peon is in charge of the signing is just going to do it.

Something isn't being explained; Garrett seems to be taking this whole thing way too seriously.

RH should stop trying to make the system "secure"(marketing term) by secureboot standards, and just keep on trying to make it secure by their customer's standards (you know, the people who actually pay Red Hat) like they have been doing for the last decade or two. Pay lip service to secureboot's bullshit, give 'em the stock RH grub2 and see if they'll sign it. If they don't fall for that, then give 'em the dedicated-to-loading-a-RH-kernel version of grub2 (or however it is that the kernel gets loaded) combined the full blast of immensity that is the existing Linux kernel. By the time you get to that second try, the $99 service is already losing money. Grind them down from there, until they give up on the enormity of the task and just sign the damn grub2.

Someone who takes only $99 isn't thinking about all the ways a kernel can restore power to the admin. Even if they're smart enough, they don't have the time.