| ▲ | Galanwe 2 hours ago | ||||||||||||||||
> id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with The firmware of the device being a binary blob for the most part... Not like I trust it to begin with. Whereas my open source Linux distribution requires me to disables SecureBoot. What a world. | |||||||||||||||||
| ▲ | WhyNotHugo 2 hours ago | parent | next [-] | ||||||||||||||||
You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it. There's also plenty of folks combining this with TPM and boot measurements. The ugly part of SecureBoot is that all hardware comes with MS's keys, and lots of software assume that you'll want MS in charge of your hardware security, but SecureBoot _can_ be used to serve the user. Obviously there's hardware that's the exception to this, and I totally share your dislike of it. | |||||||||||||||||
| |||||||||||||||||
| ▲ | repelsteeltje 2 hours ago | parent | prev [-] | ||||||||||||||||
+1 An unsigned hash is plenty guard to against tampering. The supply chain and any secret sauce that went into that firmware is just trust. Trust that the blob is well intentioned, trust that you downloaded from the right URL, checked the right SHA, trust that the organization running the URL is sanctioned to do so by Microsoft... Once all of that trust for every piece of software is concentrated in one organization, Microsoft, Apple or Google, is has become totally meaningless. | |||||||||||||||||