I've been looking into this recently. Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running. There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel…
Freedom and security issues on x86 platforms
11–20 of 282 posts
Re: Freedom and security issues on x86 platforms
#12Given that chip development has been hitting diminishing returns for a few years it might be time for Open Source to eat the world of processors as well. It feels like the sort of opportune market that server operating systems, databases and web servers occupied: less of a visual aesthetic and more of a better-design-wins market. It's not going to be easy - I'd guess that it would take at least 10 years for a project…
People are working on that, and it might take less time than you think: http://riscv.org/
Re: Freedom and security issues on x86 platforms
#13http://blog.invisiblethings.org/2015/10/27/x86_harmful.html http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
Re: Freedom and security issues on x86 platforms
#14> Secure Boot [...] requires FOSS users to purchase a license from Microsoft Nope.
Requires purchase of a cerficate from one of the authorities Microsoft recognises (Verisign/Digicert/...) and then the signature of Microsoft on compiled bootloader code. Either way, you have to pay and you have to get Microsoft's permission.
Re: Freedom and security issues on x86 platforms
#15Earlier quoted context omitted.
Requires purchase of a cerficate from one of the authorities Microsoft recognises (Verisign/Digicert/...) and then the signature of Microsoft on compiled bootloader code. Either way, you have to pay and you have to get Microsoft's permission.
IFF you want to support the default set of keys installed on computers that ship with Windows. Secure Boot does not prevent you from installing your own keys, in fact most linux distributions do this already and just use a shim loader signed by Microsoft, the rest of the chain is signed by custom keys (the keys are silently and automatically installed for you).
Which happens to be a case if you want to use a extension card with its own BIOS. If it is signed, what key is used? Can you resign with your own?
Re: Freedom and security issues on x86 platforms
#16Re: Freedom and security issues on x86 platforms
#17On their FAQ page: https://libreboot.org/faq , you can see the question "Why is the latest{Intel,AMD} hw unsupported?"
They go into more detail than the provided link. Also, dropped supports starts in 2008 for Intel, 2013 for amd.
The truth is: we need something like this to protect the whole boot process. But unless we can put our keys/sw in there, we will never be sure.
Re: Freedom and security issues on x86 platforms
#18Re: Freedom and security issues on x86 platforms
#19I've been looking into this recently. Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running. There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel…
Re: Freedom and security issues on x86 platforms
#20> Secure Boot [...] requires FOSS users to purchase a license from Microsoft Nope.
Requires purchase of a cerficate from one of the authorities Microsoft recognises (Verisign/Digicert/...) and then the signature of Microsoft on compiled bootloader code. Either way, you have to pay and you have to get Microsoft's permission.
On desktops and laptops I've seen, there was a way for end-user to upload their own trusted certificates and use those instead of Microsoft ones, and I think that's when done like this (when, whatever the defaults are, end-user can get in control), Secure Boot is a good idea - even though the implementations are not.
I guess there must be some ignorant (or malicious) desktop/laptop vendors that don't provide key management options, but hope there isn't many.