2019-06-14
Intel's approach to naming Xeon CPUs is pretty annoying
Suppose, hypothetically, that someone offers to pass on to you (by which I mean your group) an old server or two, and casually says that they have 'Xeon E7-4830' CPUs. Do you want the machines?
Well, that depends. As I found out in the process of writing yesterday's entry on the effects of MDS on our server fleet, a Xeon that is called an 'E7-4830' may be anything from a first generation Westmere CPU from 2011 up to (so far) a Broadwell CPU from 2016, the 'E7-4830 v4'. Intel has recycled the 'E7-4830' label for at least four different CPUs so far, the original, v2 (Ivy Bridge, from 2014), v3 (Haswell, 2015), and the most recent v4. These are not just minor iterations; they have had variations in core count, processor base and turbo frequencies, cache size, CPU socket used, and supported memory and memory speeds.
These days, they also have differences in microcode availability for various Intel CPU weaknesses, since Westmere generation CPUs will not be updated for MDS at all. I'd guess that Intel will provide microcode security updates for future issues for Ivy Bridge (v2) for a few years more, since it's from 2014 and that's fairly recent as these things go, but no one can be sure of anything except that there will probably be more vulnerabilities discovered and more microcode updates needed. This makes the difference between the various versions potentially much more acute and significant.
All of these different E7-4830's are very much not different versions of the same product, unless you re-define 'product' to be 'a marketing segment label'. An E7-4830 v4 is not a substitute for another version, except in the generic sense that any Xeon with ECC is a substitute for another one. Instead of being product names, Intel has made at least some of their Xeon CPU names into essentially brands or sub-brands. This is really rather confusing if you don't know what's going on (because you are not that immersed in the Xeon world) and so do not know how critical the presence or omission of the 'vN' bit of the CPU name is.
(It would be somewhat better if Intel labeled the first iteration
as 'Xeon E7-4830 v1', especially in things like the names that the
CPUs themselves return. As I discovered in the process of researching
all of this, the CPU name information shown in places like Linux's
/proc/cpuinfo doesn't come from a mapping table in software;
instead, this 'model name', 'brand name' or 'brand string' is
directly exposed by the processor through one use of the CPUID
instruction.)
This is of course not unique to the E7-4830, or even Xeon E7s in general. The Xeon E5 and E3 lines also have their duplicate CPU names. In a casual search to confirm this, I was particularly struck with the E3-1225, which exists in original, v2, v3, v5, and v6 versions, but apparently not in v4 (although the Intel MDS PDF does list some Xeon E3 v4 CPUs).
Intel's MDS issues have now made some old servers almost completely useless to us
Over on Twitter, I said:
One unpleasant effect of MDS is that old Intel-based machines (ones with CPUs that will not get microcode updates) are now effectively useless to us, unlike before, because it's been decided that the security risks are too high for almost everything we use machines for.
If Intel releases all of the MDS microcode updates they've promised to do (sometime), this will have only a small impact on our available servers. If they decide not to update some older CPUs they're currently promising updates for, we could lose a significant number of servers.
To have MDS mitigated at all on Intel CPUs, you need updated microcode (and to turn off hyperthreading, and an updated kernel; see eg Ubuntu's MDS page). According to people who have carefully gone through the CPU lists available in PDFs that are linked from Intel's MDS advisory page, Intel is definitely not releasing microcode updates for anything older than the 2nd generation 'Core' "Sandy Bridge" architecture, which started appearing in 2011 or so (so in theory my 2011 home machine could receive a microcode update and be fixed against MDS). In theory they are going to release microcode updates for everything since then.
For reasons beyond the scope of this entry, we have decided that we have almost no roles where we are comfortable deploying an unpatchable machine that is vulnerable to MDS. In normal places this might not be an issue, since they would long since have turned over old server hardware. We are not a normal place; we run hardware into the ground, which means that we often have very old servers. For example, up until we reached this decision about MDS, we were still using Dell 1950s as scratch and test machines.
In theory, the direct effects of MDS on our stock of live servers are modest but present; we're losing a few machines, including one quite nice one (a Westmere Xeon with 512 GB of RAM), and some machines that were on the shelf are now junk. However, at the moment we have a significant number of servers that are based around Sandy Bridge Xeons. Intel has promised microcode updates for these CPUs but has not yet delivered them. If Intel never delivers updated microcode, we'll lose a significant number of machines and pretty much decimate the compute infrastructure we provide to the department.
(A great deal of our current compute machines are donated Dell C6220 blades with Xeon E5-2680s, specifically CPUID 206D7 ones. Don't ask how much work it took to get the raw CPUID values that Intel puts in their PDF.)
If further significant MDS related attacks get discovered and Intel is more restricted with microcode updates, this situation will get worse. We have a significant number of in-service Dell R210 IIs and R310 IIs, and they are almost as old as these C6220s (although some of them have Ivy Bridge generation CPUs instead of Sandy Bridge ones). Losing these would really hurt.
(In general we are not very happy with Intel right now, and we are starting to deploy AMD-based machines where we can. I would be happy if someone started offering decent basic 1U or 2U AMD-based servers at competitive prices.)