OK, panic again: patching Spectre and Meltdown has been a disaster


#1

Originally published at: https://boingboing.net/2018/01/26/fumbling-bumblers.html


#2

On prem is looking better than the cloud at the moment. This isn’t a blanket statement but it’s true.


#3

Eh, most of the devices I use daily have operating systems juuust old enough that they’re no longer supported and not going to get patches. So… yay?


#4

So Linux or LineageOS where applicable


#5

same boat. at first, I was told that my chip ran a kernel (a word that means something fundamental to the OS, but beyond which I have no working concept of) that was 32 bit not 64 bit, which was thought to be too old to be vulnerable. But later news said that chips back to the 90s were all vulnerable so I dunno anymore. My OS stopped upgrading a long, long time ago, though.


#6

I don’t envy the developers trying to deal with this. It’s such a low level problem that it must be impossible to predict how the mitigations will affect things at the top.


#7

“Our most brilliant minds have spent decades devising architectures that shave crucial milliseconds off execution time by fiendishly-clever predictive execution schemes.”

“Yeah, about that. Turns out it’s insecure as hell. Opens up a whole giant can of worms.”

“No biggie. We’ll just kludge it at the OS level with this set of patches we rushed out in a few weeks.”

“And this won’t affect performance?”

“I promise, you’ll hardly notice it.”

“You know, I don’t think this is working as well as you said it would.”

“Really? Well, I can’t imagine why that could be …”


#8

Good idea, and as a bonus they require less resources and there’s no uninstallable bloatware.
The only problem is if someone uses software that doesn’t work on Wine.


#9

“That firmware patch we rushed out to y’all? Yeah, turns out it’s kinda broken so if you’d kindly just roll it back to a previous state that’d be super! Good luck with that…”


#10

Sadly doesn’t do much good for a MacBook Pro or an iPhone… Although actually, it looks like Apple are patching El Capitan after all, so it’s just my iPhone that has been abandoned. (Not counting various infrequently used legacy devices I keep to access older software/files/peripherals, where installing new OSes would rather defeat the purpose of keeping them.)


#11

I need to buy a new computer. I got lucky in that I ordered one in December, and was told two weeks later that it was out of stock and could not be delivered -just as this news broke. Any word on when new computers will have chips that do not share this vulnerability?


#12

Probably in 2-3 years, processor design and manufacturing setup takes that much time.


#13

Linus Torvalds has just about popped a vein over some of the patches proposed for the Linux kernel to deal with this set of vulnerabilities. Here, read just one of his extremely irate posts about the situation:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

Okay, you back? Yeah, the sound of suck is loud here. There seems to be no solution that won’t suddenly make cloud instances perform as if they’re running on a 66mhz 80486 processor…


#14

SX or DX? There’s a big difference, you know.


#15

dx has the fpu-- you may be thinking of the 386, where the sx kind of sxed.


#16

Not to mention the post-production debug period (howdy, beta tester!) and subsequent discovery of the crop of vulnerabilities inherent in the rush to deliver the new tech.


#17

Nuh-uh. At one time it gave me great pleasure to own a 486 DX over the lower priced SX model. Money well spent.

https://en.wikipedia.org/wiki/Intel_80486SX


#18

It takes years to design a new CPU, like around 2 to 4 years. You see new CPUs more frequently because multiple teams work on them, one on the current CPU, and a different team on the CPU that comes after that. Sometimes more.

So the easy answer is “oh about 4 years”

On the other hand, mitigating this in hardware that is willing to take performance hits on OS calls (as in “keep right on not checking permissions on retiring speculated instructions…go ahead and add things to branch target caches even if you are on a predicted path that was quashed, and so on”, but add clearing all of those performance enhancing things when you change privilege levels) might be something that can be squeezed into a CPU that is fairly late in the design pipeline. Maybe 6 months to a year?


#19

I’ve had a lot of fun with the whole “microcode updates released and then withdrawn” issue; especially now that UEFI updates often resist downgrades because security or something.

Going from ‘zOMG update!’ to “Update withdrawn by Intel; Target TBD” is…unhelpful when you can’t even reflash the prior version without a tool that doesn’t even have an ETA. I sure do love progress.

“Intel has changed their guidance for customers who have already deployed these microcode updates: If you are not experiencing system stability difficulties, you may decide to remain on the BIOS/UEFI level you have installed currently. For others, Lenovo is currently working with Intel to make available BIOS/UEFI updates to revert to an earlier, known stable microcode level.”


#20

ftfy :wink: