The Great Chassis Cull

The great CPU cull A couple of weeks ago we had the great Microarchitectural Data Sampling (MDS to its friends). There is something about this that is going to change more than a few patching cycles – in fact, it is likely going to obsolete hardware that would have traditionally lived on sweating the asset.

Let’s start at the top, it’s May 13th 2019 – and we have the following CVE’s presented: CVE-2018-12130, CVE-2018-12126, CVE-2018-12127, and CVE-2019-11091. Spot the poo in the pool there? It’s May 2019 right now. Three of these are 2018…. okay, there you are, I have your attention. These have been held under an embargo. But unlike Spectre Meltdown there was no breach.

“Hmmm – okay, so we got to find out later rather than sooner?! THIS SUCKS.”.

Well yes, but the difference is that the various ducks were in various rows, or as well as they could be for the day the news broke. There was no scrabbling about by chip vendors to go live with a rushed patch, there was a unified presentation ready to go. Things were good, or at the very least as good as they were going to be. So why the prediction?

Well – imagine you don’t have a need to run certified hardware. Say for example power was simply a cost of doing business, and you had the cooling capacity. You are sweating the asset on old hardware. Either pushing old beasts in VM testing environments, or you were reselling older hardware to customers at entry-level pricing. Then the vendor has no real viable patch or has no economic interest in patching CPU’s that are older than model X that entered life 201Y

But model X is still powering a third of your estate… you know the hardware you didn’t upgrade because you had no intent on upgrading the OS, as you could not afford the downtime. This is problematic, as the fixes for the likes of Meltdown, Spectre, MDS – they come in two parts – the kernel patch, which sits on top of the microcode. The microcode is supplied by the manufacturer. So in the case of Model X and those before – no fix, or half a fix.

Maybe then you had better take a seat, as what I am about to say may sting a little. What if your platform vendor also said “well if the CPU vendor is not providing a fix, there is nothing we can do either” … and cease to patch that CPU. So here we are. Not that you are running anything 2011 or older with anything less than a Sandy Bridge CPU – right? RIGHT?

Now the chances of this are curiously MORE likely than you running say CentOS 5 or earlier software – as that ladies and germs – is not going to receive a patch.

Got any gems out there running on pre-2011 hardware on a modern CentOS 7? Zero patches.

The times my friends they are a changing.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this:
Skip to toolbar