Unbelievable. Yet again, we have a post on finding x86 alternative that's most FOSS friendly. Yet again, the author is unaware of or ignores the <i>only architecture</i> that's open, has GPL cores, and an ecosystem. That's SPARC. Oracle's T1 and T2 cores are open-source to study. More appropriately, Cobham-Gaisler's Leon3 HW is dual-licensed under GPL and commercial. The Leon4 is 4-cores. SPARC ISA is open. Open Firmware exists.<p>So, why is SPARC left off in all these analyses? It's right there ready to pick up and deploy. More open, easy to acquire, and trustworthy (far as licensing) than than a POWER chip although slower for sure.
I've been looking into this recently.<p>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.<p>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 ME system rely on a couple of proprietary third party code, that has on contract with Intel explicit prohibitions of Intel ever letting anyone seeing their source, or the keys needed to sign them.<p>Also, Intel ME can't be really trusted, the code is not really "reverse-engineeringable", and it works as a full second OS of sorts, it even has its own JVM running, if someone somehow decide to inject spy software into it, you will never know, also I assume that the first destructive virus to latch into that stuff, will take the world truly by surprise depending on when it triggers (for example if it spreads silently but triggers the destructive payload on a specific date).<p>Also, these features can be abused to abuse the market itself, for example by intentionally making the hardware underperform, and then sell "superior" hardware that has the only difference some software.
ARM 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.<p>Ironically, it is usually the bootloader that is/requires a blob or it is the DTB.<p>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.<p>The push for platform security is also a push for platform ownership. Tinkering/hacking/your ability as a hardware owner is at ends with corporate security needs and that is a shame.
Intel ME checks to see if a certain portion of the BIOS flash memory is writable before it allows the main OS to boot.<p>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.<p>It's so disappointing that Intel undermined the entire trusted computing stack for some unproven ideas of around ME revenue generating opportunities.
Joanna has proposed a model where we minimize the trust we put in x86 with a peripheral. Seems like a plausible path forward to me.<p><a href="http://blog.invisiblethings.org/2015/12/23/state_harmful.html" rel="nofollow">http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...</a>
Given 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.<p>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.<p>It's not going to be easy - I'd guess that it would take at least 10 years for a project to get any sort of traction outside of a very small niche group.
Check libreboot.org<p>On their FAQ page: <a href="https://libreboot.org/faq" rel="nofollow">https://libreboot.org/faq</a> , you can see the question "Why is the latest{Intel,AMD} hw unsupported?"<p>They go into more detail than the provided link. Also, dropped supports starts in 2008 for Intel, 2013 for amd.<p>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.
Hmm. OK, I have two questions - maybe somebody here has answers:<p>1) "...these proprietary blobs could easily contain code to
exfiltrate encryption keys, remotely activate microphones and cameras..."<p>This seems basically impossible to actually achieve in reality though, because there will still associated network traffic that can be sniffed, and will have been by now, right? I mean, it is plausible that somehow we all just failed to notice that our computers are sending video traffic to the NSA without our noticing it?<p>I can imagine this happening on phones, where the baseband chip is much harder to actually sniff. But through my LAN? I doubt that.<p>2) Let's imagine that this post is entirely true. Why do Intel and AMD do this? If it's not part of a grand conspiracy, then why? Clearly there are far easier and cheaper ways to achieve what they view as security that don't require such a crippling approach. What's the upside to them?
And it's getting worse, SGX[1] allows 3rd party encrypted binary blobs to run on your CPU without being inspectable.<p>It's sold as way to protect your secrets from malware. But it more likely will be used to run DRM code on the user's computer while treating the user as a hostile entity.<p>[1] <a href="https://software.intel.com/en-us/sgx" rel="nofollow">https://software.intel.com/en-us/sgx</a>
The way to blow this wide open is to catch Intel's "management engine" doing something really bad and publicize it. It could do for Intel what John German did for Volkswagen AG.[1]<p>One approach would be to build some honeypots likely to attract attention. Give them a job that's not too traffic intensive but is suspicious, such as encrypted IRC. Record all traffic in and out of the box using external hardware. Get them fake encrypted traffic from suspicious sources (Tor, strange sites in suspicious countries, etc.) Wait for strange packets to show up that are not meaningful to the host software but cause something to happen on the target.<p>[1] <a href="http://www.bbc.com/news/business-34519184" rel="nofollow">http://www.bbc.com/news/business-34519184</a>
There is also an additional possibility: Recycle old computers. A Intel 2008 laptop performs OK with a modern GNU/Linux with an efficient Desktop (for example XFCE4). This also helps avoiding CO2 emissions, saves rare earths and energy. And it is a statement against a unsustainable throwaway society.
The fight is increasingly political, so advocate and donate where you can.<p>We lose when we give up, I suppose. I know what the Libreboot guy said before on his blog, alluded to here, but this is why, as crusty as some might find him, we most generally support Stallman's politics.
What about VIA x86 CPUs? <a href="http://www.viatech.com/en/silicon/processors/" rel="nofollow">http://www.viatech.com/en/silicon/processors/</a> Do they implement some "secure boot"-like features?
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.
I'd personally like to see the FOSS community try to embrace the POWER architecture: Ubuntu/Canonical are major members of the OpenPOWER foundation [1], so at least an entity sympathetic with our philosophy has an influence on the architecture.<p>[1] <a href="http://openpowerfoundation.org" rel="nofollow">http://openpowerfoundation.org</a>
This sounds similar to basebands on cellular devices: Subsystems controlled by the vendor, not accessible from the 'user' system, remotely updatable and with access to everything.
Earlier posts around the same topic:<p><a href="http://blog.invisiblethings.org/2015/10/27/x86_harmful.html" rel="nofollow">http://blog.invisiblethings.org/2015/10/27/x86_harmful.html</a>
<a href="http://blog.invisiblethings.org/2015/12/23/state_harmful.html" rel="nofollow">http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...</a>
There's an related Youtube video from Igor Skochinsky's REcon 2014 talk that I watched this week & found interesting:<p><a href="https://www.youtube.com/watch?v=4kCICUPc9_8" rel="nofollow">https://www.youtube.com/watch?v=4kCICUPc9_8</a><p>May be also be interesting to others wanting further information.
I wonder if Apple might do something about this. They don't care so much for the FOSS side of things, obviously, but I wonder if they might demand chips from Intel without the management engine, because it's a potential attack vector they can't control.
This is the main reason that I'm reluctant to upgrade my 5-year-old AMD Phenom II processor.<p><i>> MIPS is often overlooked. However, China has revived this architecture for general purpose computing with the Loongson core...</i><p>Baikal-T1 [0] is another interesting MIPS processor that I'd like to play with (or maybe even use).<p>[0] - <a href="https://www.linux-mips.org/wiki/Baikal" rel="nofollow">https://www.linux-mips.org/wiki/Baikal</a>
Even if the ME was opened, the chips themselves are complex enough that nearly anything could be hidden. State machines that enable backdoors from instruction sequences can be pretty small (triggering these from a preferred vector, such as a web browser, seems hard-ish though).
It seems superficial to concentrate on a few kilobytes of binary blobs as a security issue when millions of logic gates are also hidden from user scrutiny by design in most computers. That the number of people you have to trust now includes firmware developers in addition to hardware designers is a small movement in the scheme of things, though it may be a movement in an undesirable direction.
Dependence on a few companies to design and make processors will not work in the long term. Open source processor design that can be manufactured by anyone is the way out of this problem. Even if this never happens the attempt to go there is enough to make the large companies involved with cpus beg and serve.
Theoretically one way to correct it is to have an external device that blocks network activity going in or out.<p>Yes, I realize you could get around this. The superblob could be a) looking for patterns in JPGs for input, and b) stenographically encoding output into...anything the user is doing.<p>Sigh. Nevermind.
I think that, given a large enough group of people willing to make a mass-purchase of CPUs, Intel would be likely to listen to requests for a batch with an open-sourced Management Engine component, or some shim akin to the one RHEL uses to boot UEFI in Secure-Boot mode. (mentioned it on /r/ReverseEngineering a few months back.)<p>I don't know who to reach out to at Intel on that suggestion though.<p><a href="https://www.reddit.com/r/ReverseEngineering/comments/3pwxjn/rreverseengineerings_weekly_questions_thread/cwdpspb" rel="nofollow">https://www.reddit.com/r/ReverseEngineering/comments/3pwxjn/...</a>
While I would love a contemporary performance computer that can be trusted, no such device is even remotely possible in the manufacturing and fabrication ecosystems of today. Consider for just a moment ALL the chips inside the box. All the microcode, all the ROM, all the places something could be intentionally hidden. The idea that you could buy some parts on the internet at retail price that could satisfy the truly paranoid (ie defense & espionage communities) is ridiculous.<p>On the other hand, it still is probably possible to prevent a computers unrestricted access to the internet. For now at least.
When I saw RISCV mentioned as an alternative, I had to check the date twice to make sure it wasn't an April Fools'. I understand the concerns and all, but wish the alternatives were a little better picked out.<p>Most people already mentioned SPARC and ARM as alternatives, so I won't delve into those arguments other than point out that there will _always_ be commercial interests at stake here - hardware, unlike software, requires considerable material resources to create* and distribute (and is still harder - and therefore rarer - to create for its own sake), so there won't be a wide variety of viable options out there, and new CPU architectures don't grow on trees.<p>Better to lobby for open specs on the "offending" bits of hardware, really.<p>* - yes, software creation can also require material resources (and a whole lot of time, which can be expensive). Let's not belabor that point...
> POWER is the only architecture currently competitive with Intel in terms of raw
performance, and boots using a fully FOSS firmware with no DRM
antifeatures embedded.<p>That's pretty cool. This combined with some benchmarks I saw for server workload on POWER8 will hopefully revive some interest in the platform.
Opterons from 2011-2012 are still available and seem to be the best option to me for this purpose. They're reasonably performant (16 cores...), affordable and there are plenty of mainboard options. Software support is excellent of course. I'm just not sure how valid the "pre-2013 AMD is safe" claim is, since vendors have been known to include some remote management technology like Intel's ME in earlier versions before making it a standard feature.
1) <i>requires FOSS users to purchase a license from Microsoft to boot FOSS on affected machines that lack an appropriate Secure Boot override.</i><p>What "appropriate" Secure Boot overrides are available?<p>2) <i>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.</i><p>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?
This is a one-sided view. It can, and also is, used to implement theft-protection, thanks to which the police tracked the guy, he got convicted and I got my expensive laptop back. Yes, the guy reinstalled the OS, but the tracking SW survived precisely thanks to these technologies.
Okay, so we get a pile of FUD (Secure Boot and Intel ME are DRM features now? 'kay), no acknowledgement of the actual security threats that compel Intel, AMD, Microsoft and the OEMs to adopt these measures, and an appeal to dump x86 for ARM (um), MIPS (uhhhhhhh), POWER8 (wat), and RISC-V (how?). What is the point of this, exactly?