The UEFI SecureBoot Saga For Linux Continues

[linux5850]

Barring firmware backdoors

Barring firmware backdoors

I think that's the real purpose of secure boot and UEFI. Not that there isn't a legitimate case for secure booting but if it prvents you from examining ALL the source code and the firmware then you don't really know who has ultimate control of your pc and data.

[allquixotic]

will it be possible to just flash a coreboot with flashrom over the BAD and EVIL UEFI ?

Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).

[linux5850]

secureboot is coming whether you like it or not. You may be able to disable secureboot in the bios, but every bios vendor will implement it differently and some may forget to implement it at all. How do you tell a new Linux user that they have to hit F11 or maybe Delete or maybe F2 during the first few seconds of boot and then wade through a bunch of bios menus to disable a feature called _secure_ boot (let that sink in) just so they can try out this new Linux thing. Kind of a high bar. Realistically you need to support secureboot if you want your OS to be accessible to a wide audience.

I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.

[allquixotic]

in your world professionals only use UEFI ? i think REAL Professionals use coreboot in the bios flash rom and a hardware jumper to set the boot rom to read only

LOL !!! tell me how do a hacker BEAT this security solution ?

That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.

This is what secure boot does, but instead of network data, it verifies executable code on disk.

My personal commitment to fight secure boot's unnecessary restrictions on regular users is this: I will never purchase a consumer device (PC, laptop, tablet, smartphone, etc) that has Secure Boot enabled, and cannot be disabled. Those devices can sit on the shelves in the stores, and I will buy devices that let me customize the operating system how I want to.

However, if someone expresses interest in using secure boot in an enterprise context (a server, I mean), I will probably let them know that it can be a good thing, if you know what you're doing. But it does add a lot of unnecessary headache to the configuration/installation of the operating system and software, so we'd have to perform a feasibility investigation to make sure that there are no roadblocks.

[disi]

Easy enough: avoid any hardware with a Windows 8 sticker?
This is what I am going to do...

Little example, me buying a netbook:
1. tell the vendor to rip out the hard drive and put a SSD in
2. do not bother to install Windows on it and keep the licence
3. after some research, the third vendor was OK with that

[Kano]

@Q

Kanotix is definitely not dead, maybe look at our homepage, we just release a Hellfire (squeeze) update and a Dragonfire (wheezy) preview.

But if EVERYBODY can get a signed bootloader then this system is absolutely pointless. For x86 you just have to find a setup option to disable secure boot - usually secure boot can only work in uefi mode anyway. So when you would force a boot via csm (and bios emulation) how should secure boot be active if thats done via quick boot selection?

If you see secure boot as something positive to your own security that means that could be sure that nobody managed to put in a spy module to save your encryption keys if you encrypt your data like it is possible when you hijack the mbr for this and then execute maybe truecrpt later but store the key.

I don't understand why ms would give away a signed 3rd party efi loader, you can be 100% sure that it will be used for exploits. If you dont need security features you can disable em on your own. It would be interesting to know if there is a uefi spec to update the included public keys. Basically it should not be that hard to do when you have got access to the uefi, you can extract, change (there are several tools to modifiy uefi, just for another purpose currently) and flash your own keys.

Even if the key area would be write protected after first write you could still replace the eeprom chip, which is a piece of cake on a desktop system, well could be tricky on a laptop. When YOU are able to control it, then you can gain a little bit more security, if you cant it would be just like without.

[steveriley]

I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.

In the comments section, someone asked about TPM, and the response was that SecureBoot is designed not to require one.

[Kano]

No i wont because if somebody does not find the option to disable secure boot he is most likely not able to use linux as well...

[Kano]

I think there are better reasons to use Kanotix. But you should not mix up standard uefi booting with secure boot. uefi boot is really cool when done correctly - especially with a kernel with efi stub. It is a bit weird that you can use "rdev" now for that purpose which was already dropped from utils-linux because nobody used it...

[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...