UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run."[0]
> Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run.
This means: 1. You trust Microsoft (you delegate the trust of your data to Microsoft).
2. You trust that Microsoft certificate will not be revoked.
Sorry, for me, secure boot is when i have the keys. When someone else has them they also have my data.
You do not understand how secure boot works. As a developer, I pick my own keys to use for signing on my devices. I do not trust Microsoft, but that’s moot: they have nothing to do with my use of secure boot. Source: I an a senior embedded engineer that has implemented secure boot for paying customers, across multiple devices and processor architectures.
That said, I despise vendors that lock down their devices using secure boot. This is unquestionably hostile behavior toward consumers, as the protection from malware usually also prevents user modification.
I wish there was a way to force disclosure of this anti-feature, as I actively avoid buying products that do not allow me to load my own keys and images.
Microsoft doesn't have access to your hardware. How would they exfiltrate your data without also having your TPM? If a key is revoked then you... disable secure boot.
Why do you trust a closed down chip like TPM, why do you trust secure-boot when the only time it's verifying the kernel is at boot time? Why trust something like IntelME? Why trust something like a proprietary UEFI?
I don't trust anyone, especially boot drives that have been exposed to the internet. That's why I would like a system of trust between my hardware components until the OS takes over. Why do you trust your boot drive?
Because most of the industry does, and companies have little choice in the matter. That's the power (and the convenience) of a monopoly. For your small-scale setup at home you are free to do as you wish (you can even use a RaspberryPi or whatever, although in such cases you are dealing with at least partially closed-source hardware anyway).
Does this mean that I need to get the private key to Microsoft for them to sign? Can Microsoft then record my key and impersonate me?
Or can Microsoft sing an NSA backdored Linux so it appears that is "secure/genuine"?
If the answer is yes to one of those then for me seems fair that someone would say that "it is not secure book if I can't remove Microsoft)NSA keys) and put my own and confirm it worked)" , seems to be a push for sanity that failed , like how we failed and we have now DRM into the browser.
Not require. But without a requirement, vendors are making their own choices. Some have gone with one-time programmable fuses to store the keys. Once programmed, only images signed with that key can be used. Otherwise, the device is a brick. Those vendors deserve to burn in hell (in my opinion as an embedded engineer that has implemented secure boot on a variety of platforms).
MS has been slowly prepping Windows on ARM to be viable as "Enterprise" device and for that it needs owner-controlled Platform Keys (to comply with their own requirements for enterprise offerings)
If you don't mind me asking, how did you get into embedded development? I'm trying to sample various types of development and see what I enjoy, and embedded development seems quite interesting to me though I've never done more than an arduino.
OpenBSD chooses to have an opinion on standards according to the project's own security criteria - simple inclusion/exclusion of a given technology X while ignoring their decision process is not a valid reason to critique the security posture of the project as a whole.
I fail to see how secure boot is worse than nothing. I don't need to even begin to think about supply chain attacks when the hardware in my house doesn't have trust between its components.
Read it again. I'm saying your concern of supply chain attacks on secure-boot and TPM are like worrying about the ash on your shirt while your house burns down. It's far easier to pwn a system with pre-boot injections on a system without signatures than one with them. Don't like where the signatures come from? Fine. That doesn't make the system have some mysterious backdoor or do whatever sensational magic someone told you it does.
UEFI is an abomination. Even putting aside removing user control the implementation is horrible and bloated. Just try building a bootable image for UEFI vs BIOS.
The title idea is very good but the implementation and the shady politics behind it are horrible. There's coreboot and libreboot. Hopefully either takes off or something else along the lines comes along.
I mean building a bootable image compatible with UEFI vs compatible with BIOS. Not building UEFI nor BIOS.
Like creating an "EFI System Partition" (FAT-based) or having a simple BIOS bootloader (usually with 2 stages, MBR + partition). With UEFI, it feels like you are booting an extra OS in between.
UEFI brings a lot of logic to the firmware. If you just want to boot one OS it's overkill, IMHO.
Oh you mean disk image; I was thinking ROM image. Yeah, it does seem to be very large and seemingly much of it unnecessary for booting. I wonder what led to that situation. It seems more like a replacement for the BIOS and DOS, not just the BIOS. I am surprised we don't see more people using it like that just for fun.
https://isopenbsdsecu.re/mitigations/secure_boot/