This project is about having a standard, physically secure computer that anyone can use – as open as we can make it. All these concepts are important, and they mean that x86 and flawless out-of-the-box Windows support are not optional. There are reasons everyone is using x86, even in the security community and in governmental agencies around the world: compatibility, performance, and security. Make no mistake, some of us own Yeeloongs, and others are veterans of the silicon industry. We would love to ship a completely free and usable desktop processor, but we know very well that there is no alternative. Some people seem to think that switching to AMD can solve problems related Intel’s Management Engine (ME), microcode, or SMM. It doesn’t, as there are equivalents of these technologies in all recent x86 processors.
How else is there any progress when the community's just pulling everyone down with this "it's no good if it isn't completely perfect" crap?
The parent comment is right to point out this computer has a fully functioning Intel ME, running it's secret, unaudited, possibly backdoored, firmware on the co-processer which runs even when switched off, and can interact with the rest of the system undetected. Any "secure" system with this foundation isn't really secure.
IMHO a product which would focus more on this (like libreboot laptops) can make a bigger claim on doing something for security than this.
Care to elaborate?
> It still has a backdoor baked in.
True, but this does not explain or validate your previous statement. You are saying: "A has these pros and this con, B has the same con but none of the pros, hence A and B are the same". This sounds like a poor argument to me.
> Keep on downvoting because you disagree, though.
I believe that you are being downvoted because your last two comments are poorly articulated.
...have to trust Intel's publicly available documentation. In other words, this has to be taken on pure faith that it does exactly what they say it does in exactly the way they say it does it, and no more.
The problem with ME is that it consists of unauditable code that could be doing literally anything on the computer, completely transparent to the user. Furthermore, even if there is nothing untoward happening when the chip leaves the fab (again, must be taken on faith), a documented threat is having hardware interdicted, modified, and sent on its way.
It would have to get swiped on the way from the manufacturer to the OEM. Once the OEM has sent it out, it's protected against this exact kind of attack. And while it may make sense for interdiction of a single package to a known target, doing the same with an entire batch of chips seems prohibitively expensive.
>Given everything that has to be in place for vPro/the ME to work
Again, per Intel's documentation. For all anyone here knows, data exfil begins the moment a certain sequence of bits crosses the right registers - and it's not like this is beyond the capabilities of what ME lets you do.
There is no good reason that the entire subsystem can't be disabled by the user, permanently. But, come to find out about it, the chips are configured to shut the system down within 30 minutes if the ME firmware doesn't pass checksum.
That, in my mind, puts it uncomfortably close to malware territory. Every one of these concerns evaporate if the ME area could be wiped or dumped - it's not as if remote management is some secret competitive advantage.
The point I'm trying to convey here is that every piece of information available on this thing comes straight from the horse's mouth, and the horse is not necessarily a trustworthy actor.
For both ME and debugging purposes, Intel's chips are wired through and through in ways that could do interesting things in the hands of an attacker. ME gives attacker the ability to act. What you just said is you believe Intel's technical statements and marketing claims about that. In reality, you can't know about any digital, analog, or RF backdoors it creates unless you get whole thing torn down at transistor level with analysis by people who understand all those categories. It's normal in ASIC work, for trade secret protection and dodging patent suits, for firms to use tricks to hide I.P. in I.P.. They also reduce NRE & mask costs by putting circuitry in whole families of product while only visibly enabling them in some at factory. Still there, though. The guy that originally taught me about this stuff gave an example where one component they used had wireless connectivity because it was a mobile SOC where they visibly, but only temporarily, disabled some components to make it look like a microcontroller and I/O combo. They were trying to score extra ROI off it without building dedicated product.
Lots of stuff like that in ASIC design. Hell, the firewall industry should've already taught all of you this lesson. Grimes reviews of them showed they often had all kinds of undocumented stuff running that wasn't advertised but was result of poor quality or some internal benefit. He rarely ran into one that did what it advertised and only what it advertised. That wasn't even open-source testing. ;) Intel's stuff is a combo of their specs, their implementation, the analog circuits, the effects of the materials involved on those, and the interactions with other things on the board if you're talking EMSEC. There's no way for you to verify these are secure by reading their public claims. This is neither a new nor uncommon problem.
https://www.orwl.org/wiki/images/9/95/SowDESIGN-SHIFTORWLPUB...
AMD has something similar to the Intel Management Engine: https://libreboot.org/faq/#amd
http://www.oracle.com/technetwork/systems/opensparc/openspar...
The ASIC implementation was nice:
https://en.wikipedia.org/wiki/UltraSPARC_T2
On a 65nm node... very outdated one... it might get 8 threads in 8 cores at 1.6GHz each with hardware RNG, crypto accelerators, and hypervisor support. That's the kind of implementation that would be useless for an open-source, secure workstation, server, or HPC node. ;) Especially if one slightly increased single-core performance or cache when porting it to 45nm.
Forget that, though. Let's see what IBM will charge for their admittedly-faster pile of complicated silicon that only certain people can see which they've already turned into non-backdoored chips for you. ;)
The cool thing about open-source CPU's is one can always improve on them to, say, have an extra dozen cores on more recent nodes. Like Oracle does but probably less impressive with less money.
Somebody tried to use a university department's T2 because it was unused and reasonably parallel for some experiment on hashing.
Single core SHA1 speed on a t2 was ~300KB/s or so. Even with its 32 threads I recommended going for any ancient desktop that happened not to be used for a couple of days because the experiment would finish much faster there. Those desktops were about Core Duo class and managed 50-100MB/s SHA1 throughput (I think, it's been a couple of years).
"SPARC chips before T4 under-perform on GMP. This is not because the GMP code is inadequately optimised for SPARC, but due to the basic v9 ISA as well as the micro-architecture of these chips. The T1 and T2 chips perform worse than any other SPARC chips; they compare to a 15 year older 486 chip."
ouch!
Note: There's always my other recommendation of turning open-source Leon3 into a multicore. Im curious what it or Leon4 get on such a benchmark versus Intels on similar process nodes.
It's worth mentioning that there is at least one OSS implementation of a TEE software stack, OP-TEE, making this even less of an issue. Assuming your device/soc mfg doesn't lock you out.
http://www.linaro.org/blog/core-dump/op-tee-open-source-secu...