What could one do to make it possible to have ME-less x86 in the future?
Another architecture all together, designed from the ground up to support a free and secure system, seems a better bet.
More generally if the processor's going to have any dynamic internal logic then that has to run somewhere. Frequency scaling, wake-on-lan, microcode updates... you probably do want an ME-style embedded management processor that runs the processor's firmware just as you would for any other peripheral (hard drives, wifi controllers and so on all contain their own embedded ARM cores these days). ME itself isn't the issue - having what runs there be open and inspectable is.
Qualcomm will first minimize its risk going into the PC market by making its mobile chips a bit more optimized for the PC market. But if that goes well and all, it may eventually go "upmarket" with higher-end chips, which will require their own R&D and so on.
However, I don't know if that necessarily means we'll have a more open alternative to Intel. Evidence so far seems to show that Qualcomm may be an even bigger bully than Intel was or is, so I would not look up to Qualcomm to being a savior for the market, but more like the tyrant that replaces the previous tyrant.
Joanna Rutkowska, Qubes founder, is the person who brought up intel ME as a problem in her paper Intel x86 considered harmful (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf).
Also, the ME appears to be a nice one-stop-shop for compromise. It is the janitor's entrance; it is right there in the name.
[1]: https://openpowerfoundation.org/ [2]: https://www.crowdsupply.com/raptor-computing-systems/talos-s... [3]: https://www.raptorengineering.com/TALOS/prerelease.php
If I can peek and poke around in your RAM as I please, no amount of cleverness is going to save you if my intentions are malicious.
(Don't worry, though, I have no such intentions, and I don't fiddle with other people's RAM as a matter of principle, unless they ask me to. ;-))
If such a machine with reasonable specs (I do not expect a 64-core 256-GB-RAM-monster) could be brought down to the 1000 $/€ price range, I would seriously look into it.
(I am not sure how realistic that price range is, though.)
What about Loongson? IIRC, Richard Stallmann uses a Notebook based on it, because it has free firmware. Performance is probably not breathtaking, but it exists. Does somebody know if there are Desktop machines built around that chip?
They should have offered a bare version with just the board, ram and maybe video card (to ensure comparability). They needed the ~$1k USD hobbyist market.
It seems like the goals were way too high, like the Ubuntu Edge.
For example: compiler is to software as X is to hardware. What is X? And how does one go about creating their own X?
But at any rate it's not unfeasible or unknown right now to deal with 100-200W worth of TDP in big 17" (or even 21"(!!!)) notebooks, and there does seem to be a functional (albeit niche) market for it. So at that range it'd be feasible in principle to stick in a low end POWER8 and smallish but functional GPU and have a "notebook POWER8 system", but it'd be a compromised machine in terms of what we'd normally find desirable in a mobile system.
POWER9 (which I think is still slated to go online in the Summit & Sierra supercomputers this year?) is supposed to have improved energy efficiency and management features, which though aimed at scaleup/scaleout of course might help out a bit in other settings in theory. But even so it'd be a tougher chip to build in an SFF system around let alone a notebook. Any potential buyers would have to care a very great deal about what it brought to the table.
One could lock all the devices that can store data: https://blog.invisiblethings.org/papers/2015/state_harmful.p...
"The general idea is to remove the SPI flash chip from the motherboard, and route the wiring to one of the external ports, such as either a standard SD or a USB port, or perhaps even to a custom connector. A Trusted Stick (discussed in the next chapter) would be then plugged into this port before the platform boots, and would be delivering all the required firmware requested by the processor, as well as other firmware and, optionally, all the software for the platform."
So, given we can control most inputs to hardware, and most outputs, it seems possible to objectively identify when the HW is misbehaving (such as "A" produces network output that "B" does not). It wouldn't nail down which piece of hardware was compromised, but it would help identify that hardware is compromised.
It will never be _that_ easy, of course... but it seems possible.
They did offer that, but the board alone was $3,700.
https://www.dwheeler.com/essays/scm-security.html
Now, let's say you want to know the compiler isn't a threat. That requires you to know that (a) it does its job correctly, (b) optimizations don't screw up programs esp removing safety checks, and (c) it doesn't add any backdoors. You essentially need a compiler whose implementation can be reviewed against stated requirements to ensure it does what it says, nothing more, nothing less. That's called a verified compiler. Here's what it takes assuming multiple, small passes for easier verification:
1. A precise specification of what each pass does. This might involve its inputs, intermediate states, and its outputs. This needs to be good enough to both spot errors in the code and drive testing.
2. An implementation of each pass done in as readable a way possible in the safest, tooling-assisted language one can find.
3. Optionally, an intermediate representation of each pass side-by-side with the high-level one that talks in terms of expressions, basic control flow (i.e. while construct), stacks, heaps, and so on. The high-level decomposed into low-level operations that still aren't quite assembly.
4. The high-level or intermediate forms side by side with assembly language for them. This will be simplified, well-structured assembly designed for readability instead of performance.
5. An assembler, linker, loader, and/or anything else I'm forgetting that the compiler depends on to produce the final executable. Each of these will be done as above with focus on simplicity. May not be feature complete so much as just enough features to build the compiler. Initial ones are done by hand optionally with helper programs that are easy to do by hand.
6. Combine the ASM of compiler manually or by any trusted applications you have so far. The output must run through assembler, linker, etc. to get the initial executable. Test that and use it to compile the high-level compiler. Now, you're set. Rest of development can be done in high-level language w/ compiler extensions or more optimizations.
7. Formal specification and verification of the above for best results. Already been done with CompCert for C and CakeML for SML. Far as trust, CakeML runs on Isabelle/HOL whose proof checker is smaller than most programs. HOL/Light will make it smaller. This route puts trust mostly in the formal specs with one, small, trusted executable instead of a pile of specs and code. Vast increase in trustworthiness.
@rain1 has a site collecting as many worked examples as possible of small, verified, or otherwise bootstrapping-related work on compilers or interpreters. I contributed a bunch on there, too. I warn it looks rough since it's a work in progress that's focused more on content than presentation. Already has many, many weekends worth of reading for people interested in Trusting Trust solutions. Here it is for your enjoyment or any contributions you might have:
If performance is not a huge concern, one could (in theory of course) design software so cpu/memory-hard that the ME is simply unable to perform meaningful key material recovery for FVEY.
http://opencircuitdesign.com/qflow/
Start with a simple CPU and memories you can hand-check sent to a 0.35-0.5 micron fab that's visually inspectible. Then, after verifying random sample of those, you use the others in boards that make the rest of your hardware and software. You can even try to use them in peripherals like your keyboard or networking. Make a whole cluster of crappy, CPU boards running verified hardware each handling part of the job since it will take a while. You can use untrusted storage if the source and transport CPU's are trusted since you can just use crypto approaches to ensuring data wasn't tampered with in untrusted RAM or storage. Designs exist in CompSci for both.
So, you'll eventually be running synthesis and testing with open-source software, verification with ACL2 a la Jared Davis's work (maybe Milawa modified), visual inspection of final chips, and Beowulf-style clusters to deal with how slow they are. And then use that for each iteration of better tooling. I also considered using image recognition on the pics of the visual trained by all the people reviewing them across the world. More as an aid than replacing people. Would be helpful when transistor count went up, though.
Other links:
https://www.cs.utexas.edu/users/moore/publications/acl2-pape...
Do TCP timings and retransmissions count as difference in outputs?