It's great that these guys pushing POWER8 at least have a workable situation, but at least for me, throwing $3,700 at a motherboard (Alone!) just isn't feasible. I would love to be free of proprietary firmware, but it would seem that's only for people better off than myself.
Freedom and security issues on x86 platforms
21–30 of 282 posts
Re: Freedom and security issues on x86 platforms
#22Intel ME checks to see if a certain portion of the BIOS flash memory is writable before it allows the main OS to boot.
What x86 Chromebooks do is they allow that region to be writeable but then zero that region on every boot. If your ME was backdoored, it was shipped that way from the factory.
It's so disappointing that Intel undermined the entire trusted computing stack for some unproven ideas of around ME revenue generating opportunities.
Re: Freedom and security issues on x86 platforms
#23I'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…
I'd think it would be easier and more profitable (more convenient for "customers" than buying new hardware) to sell the "speed unlock" solution, much like cryptolocker does with your personal data.
Re: Freedom and security issues on x86 platforms
#24Check libreboot.org On 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.
I was at FOSDEM this year (2016) and there was a talk from the leader of LibreBoot.
Honestly, his talk on the state of the project was very bitter. He literally said that there is absolutely no hope that LibreBoot will ever be able to cope with ME, and that the fight is over since 2008.
As much as I would absolutely love to be able to run a free firmware, unless there is a major change/outsider in the hardware manufacturer world, it seems very unlikely that it will be possible on current x86 architectures.
Re: Freedom and security issues on x86 platforms
#25What about VIA x86 CPUs? http://www.viatech.com/en/silicon/processors/ Do they implement some "secure boot"-like features?
Re: Freedom and security issues on x86 platforms
#26Earlier quoted context omitted.
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).
> IFF you want to support the default set of keys installed on computers 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?
You can add your own without wiping the pre-installed ones.
Re: Freedom and security issues on x86 platforms
#27Intel ME checks to see if a certain portion of the BIOS flash memory is writable before it allows the main OS to boot. What x86 Chromebooks do is they allow that region to be writeable but then zero that region on every boot. If your ME was backdoored, it was shipped that way from the factory. It's so disappointing that Intel undermined the entire trusted computing stack for some unproven ideas of around ME revenue g…
[deleted]
Re: Freedom and security issues on x86 platforms
#28Earlier quoted context omitted.
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).
> IFF you want to support the default set of keys installed on computers 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?
IIRC, Secure Boot spec said there must be multiple trust anchors, i.e. it's not like "user's own or Microsoft", but there can be any combination of trusted CAs (and I bet there's NSAKEY somewhere, huh).
I'm not sure about the implementations and real-world situation, but as far as I get it, with X.509 with Secure Boot generally uses, one should be able put the exact card's vendor certificate (not MS CA root one) to trust the extension card. (Sadly, I think there's no way to trust one specific signature.) I guess that's probably very non-trivial in practice.
At worst, one should be able to put their own CA (to sign their own software) and be forced to add MS CA to trust the third-party software as well. But - if UEFI implementation allows user-defined CAs - it should be possible to run your own code without asking Microsoft's permission.
Re: Freedom and security issues on x86 platforms
#29ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack. Ironically, it is usually the bootloader that is/requires a blob or it is the DTB. I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right. The push for pla…
There are plenty of boards that run using mainline u-boot and mainline Linux, you can often ignore the vendor BSP. You are right about ARM though, TrustZone is another DRM-oriented aspect of ARM-based SoCs.
TrustZone is just another processor mode and associated memory protection, nothing more, nothing less.
It's equally as incoherent to say supervisor mode and the MMU is 'DRM-oriented'.
Re: Freedom and security issues on x86 platforms
#301) requires FOSS users to purchase a license from Microsoft to boot FOSS on affected machines that lack an appropriate Secure Boot override.
What "appropriate" Secure Boot overrides are available?
2) the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL.
Other parts of the posting imply that we have no idea what the software does, but thhe statement above says we have the source code. What am I misunderstanding?