Syonyk - can you tell me why you avoid Intel. I'll probably learn something.
Short answer: They've demonstrated to me clearly, in the past 3-4 years, that they cannot reason about their chips. The endless waves of security issues coming out mean that they no longer understand their chips, and they make claims that are false at the time they make them (and it's clear they don't know the claims are false). I'm unwilling to support a company that builds things they no longer understand, and in the case of computer security, I think their chips are simply not trustworthy at this point. It's been too many massive missteps, too many "Oh, gosh, we screwed that up too?..." responses to security researchers, and too many failed patches/fixes/hacks/microcode updates/etc for me to believe they have any clue as to what's going on internally in their processors anymore. I don't know
why - but I've proven to my own satisfaction that it's true.
As a result, I'm trying to move that of my life which I can off Intel. I'm not entirely there yet, but I'm making good progress. My homeserver got swapped out some while back for AMD parts to replace the Intel parts (which I've donated to the church server with hyperthreading disabled), and the Mac Mini has been swapped out. I make heavy use of a Raspberry Pi 4 in my office, I've got an older Intel netbook that predates all the speculative execution vulnerabilities by not speculatively executing anything, and... I've still got an Intel MacBook Pro that runs the latest OS with hyperthreading generally disabled. I can't justify replacing that one quite yet, but I'm careful with it.
Long answer, sorry for technical details if you don't care:
Meltdown and Spectre showed up some while back, and were pretty devastating to the concept of a processor enforcing security boundaries. The processor enforced them architecturally - what you see in registers - but it wasn't even bothering to try to enforce them when doing the "run ahead" execution that most modern chips do (speculative execution, you keep the results and save time if you're right, throw the results away and try again if you'er wrong). One could guide the speculative execution down a forbidden path, and before the processor caught up and realized it wasn't actually allowed to do that, it had altered the state of internal resources (typically the state of cache). Through various creative techniques, one could encode data in how one disrupted cache lines and therefore read out the forbidden data. For Meltdown, in particular, on 64-bit systems, this meant that you could read
literally anything in RAM on the system if you knew how to look and ask politely. You could freely, as a random user process, read kernel memory, and for a variety of reasons, 64-bit kernels keep all of physical memory mapped into the kernel address space. So, I'm some random process with no permissions beyond the ability to run code and make a few basic syscalls, and I effectively have full read access to the entire system. Crypto keys for SSL termination, cryptocurrency wallets, passwords, you could read everything. Whoops.
However, at the time, while horrid, I was willing to give Intel some benefit of the doubt. The system did behave properly, in terms of architecturally specified behaviors, and... maybe this was a one-off thing someone didn't think through. Fine. It would be bad if they didn't know about it, because it means they don't understand the chips, but it would also be bad if they knew about it and didn't do anything to correct it. I wasn't sure which was correct, but neither one was good.
And then the world continued coming down around Intel, and I got my answers in the form of the vulnerabilities that cracked open production SGX enclaves.
SGX is a "secure enclave" that, on paper, allows you to perform private (nobody can see what you're doing) and correct (nobody can interfere with the validity of your results) calculations on a fully compromised system. Intel explicitly considers the OS and such in bounds as attack surfaces for SGX. Their claims were that even with a fully compromised, actively malicious operating system (ring 0) managing the enclaves, you could not either see into a production enclave or do something that would alter the results. They did things like encrypting the memory they used, signing pages as they were swapped out to prevent the OS from loading an old or incorrect memory page when swapping things back in, and generally made an awful lot of claims about how you couldn't mess with SGX.
All of which were wrong, at the time they were made, on the current hardware of the time.
There's a laundry list of microarchitectural vulnerabilities out there, and I'm not going to point out most of them, but two in particular violate Intel's claims about their processors and SGX.
The first was Foreshadow/L1TF/L1 Terminal Fault. This is a hardware implementation detail of the L1 cache (fast memory close to the CPU core) that means that, if page tables were misconfigured in a particular way, you could (speculatively) read the data out of another process's memory space -
including that of an SGX enclave. If you knew what you were doing, you could violate just about any security boundary in the system. User to kernel, virtual machine to hypervisor, virtual machine to virtual machine, OS to SGX... just ask nicely, and you can read out what's going on. In particular, you could read the memory out of an SGX enclave. Because SGX enclaves store their register state in their memory when exiting, you could also read out the register data from the current enclave execution state. Throw in some other tricks and techniques to single step an enclave, and you could quite literally read out the entire memory and register state of a production SGX enclave, at every single step of execution. This includes private keys used by the loaders and such that you weren't supposed to be able to read, ever.
Whoops. So much for "Can't read the enclave." But, hey, at least you can't mess with it, right?
Except, you can. Plundervolt is research in which the OS (explicitly untrusted, remember) can make use of an undocumented (!) hardware configuration register (MSR) for undervolting the processor. This allows the OS to improve power efficiency, but as implemented, it also allows the OS to lower the voltage just enough that certain complex instructions start faulting. You can, as the OS, edge the voltage down until multiply and AES encryption operations start faulting, but everything else works fine. These instructions have a longer chain of transistors involved and will show the signs of overclocking/undervolting first.
So, you run the chip down to the edge of faulting, launch the production SGX enclave, and... it runs at the reduced voltage, with multiply and AES instructions faulting in the predictable ways. Which means the enclave gets the results wrong. Not only does this usually allow you to pull out crypto keys (again), it means that the claim that the OS can't impact operation of the enclave was also wrong.
And the list goes on, and on.
https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability has a lot of it.
As far as I'm concerned, these demonstrate (well enough for my convincing) that Intel (a) can no longer reason about their CPUs and all their behaviors, because (b) they're simply too complex to reason about anymore, even with literally all the data about how they're built.
And let's not discuss their hyperthreading leaks, and outright architecturally incorrect behavior on Skylake...
AMD is impacted by the branch predictor vulnerabilities (Spectre classes), and ARM is as well, because these are just fundamentally an issue with out of order and speculative execution. You can't "run ahead" without predicting branches, and branch predictors can be mis-trained. There are mitigations for some of the issues, by flushing or scrambling the branch predictors on process change, but AMD has been largely unimpacted by the other huge classes of vulnerabilities Intel is struggling to keep up with.
Does this mean AMD is more secure? Well... evidence points to yes. They seem to detect "Huh, that's weird..." and wait for the execution to catch up to resolve it in a wide range of conditions that Intel just blasts on through. I expect this might be from their long process disadvantage - mis-speculation is simply burning power, so waiting around in the oddball hard-to-predict cases saves power that is likely to have been wasted. Intel, recently, has been struggling with their process being utterly stuck, so they've been pushing the bounds of "Anywhere we can gain some performance, we must." Getting creative with speculation to save a cycle here and there does add up, as long as it's not about to blow up in your face...
So, given all that, I've been trying to move that which I can away from Intel. Some goes to AMD (homeserver, possibly my office utility NUC at some point once the comparable AMD system is in stock), some goes to ARM (Pi4, PineBook Pro, Mac Mini). I generally think that ARM is going to be the future of most computing, and so I'm more inclined to move to ARM when I can. Apple's new silicon solves the main issue with ARM - that it's been slow. The Mac Mini is, by far, the fastest computer that I have (some other stuff
might out-throughput it, but... probably not). It sips power (in a solar powered office), is blisteringly fast, and is not-Intel.
And I absolutely accept that I am being financially sub-optimal by swapping out functioning hardware, long before it's obsolete, to get away from Intel. I'm trying to do it as even as I can (selling the old Mac Mini for most of what the AS one cost), and where I can't, well... honestly, I just don't care. I'm at a point where I can live out some of my convictions/desires about computing, so I'm doing so. It doesn't have a real impact on my financial state, which is doing just fine.
Should you (in the generic sense) get rid of Intel systems? Probably not. I don't think that many of these issues are terribly likely to be exploited, but on the flip side, it's also impossible to tell that they have been exploited because they leave no traces anywhere.
You should, probably, consider a few steps if you do anything terribly sensitive on your computers, though:
- Disable hyperthreading. Plenty of ways to do this. Hyperthreads
leak. Horridly.
- Make sure you keep your BIOS and OS up to date. Install the damned updates. Yes, they slow things down. Beats some bit of Javascript being able to read out all your system memory, far as I'm concerned. There are people on this forum who still suggest using Windows XP or Windows 7, and to me, that's lunacy. I will get rid of daily use hardware when it stops getting OS updates, period.