Secure, yet refuses to implement hardware root-of-trust standards?
"What is UEFI Secure Boot NOT?
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]
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.
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.
Because HIDS with my own signed hash database and hids-exec.
But i cannot scan/proof what the UEFI TPM IntelME makes.
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).
That's a pretty bad comparison in a time when every day 100's of "industry's" get ransomware'd.
>That's the power (and the convenience) of a monopoly.
No that's the week point and inconvenience of every brand monopoly.
That's going to be a hard no.
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.
Because one of them requires ability of device owner to delete any pre-existing platform keys and load their own set.
On x86 based systems.
My understanding is that Arm systems require the opposite.
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.
(And I include ostensibly FLOSS in it as well, as shitty firmware can be worse than no firmware)
If you keep the default Microsoft keys a big YES.
Just trust secure-boot if you absolutely believe that there is no chance that there is a hidden "non detectable but updatable" key ;)
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.
Can you proof that in the first place?
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.
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.