computer slowdowns everywhere

[cellio]

This morning while I was having an uncomfortable annual preventative exam, the technician apologized for something taking so long and said the computer was slow today. I asked "you got the patch for the Intel thing?" and she gave me a blank look; she hadn't heard of the Meltdown/Spectre problem. I gave her a super-high-level summary and suggested what she could Google for later.

She asked me how much things would slow down and I said it's hard to tell -- could be 5%, could be 30%, could be worse -- depends on lots of things. She got a look of horror on her face and said "if it's that bad, we're going to have to change how we schedule appointments!".

Wow. That kind of effect had not occurred to me. I mean, there are computers with affected chips in everything these days -- medical equipment, air-traffic-control systems, sensor networks, self-driving cars... I presume that many of those systems will have to get patched, and that hardware replacements are big productions that won't happen until current systems reach the end-of-life mark, and that the consequences of slower execution could matter in some of those use cases. (Car: "stop at that red light... oh, that was back there".) Even if it's "just" diagnostic scans taking longer, what happens, logically and financially, when providers can see fewer patients per day?

I asked if the machine she was currently using was networked. It's on the facility's network only, as I expected. I said that perhaps their IT people will opt for securing the network and not applying the patch, but to myself I wondered if that opens them to liability claims or regulatory problems. It's also possible that some of these machines are specialized enough that they don't have the affected chips. I know next to nothing about embedded systems, specialized equipment like mammogram scanners, and so on.

I assume that in time this problem will be dealt with or worked around. I've already seen recommendations suggesting which patches to take and which to disable to walk that balance between reduced effects and security. I'm not trying to paint a picture of doom and gloom here. I just wonder how some of the bumps along the way will manifest.

Comments

[siderea]

I said that perhaps their IT people will opt for securing the network and not applying the patch, but to myself I wondered if that opens them to liability claims or regulatory problems.

Worse: right now, medical facilities are the big target for ransomeware. So I don't think anybody in HIT feels that perimeter security is adequate.

[cellio]

Oh, good point -- I'm used to thinking of hackers targeting money (banks, credit cards, stores that have credit-card numbers...), but that'd be for *cracking*. For *ransomware*, on the other hand, they want to do the most damage.

[madfilkentist]

I'd expect that the more a service is limited by I/O rather than processing, the less slowdown it will experience. Some of the applications you describe could be noticeably affected. Self-driving cars must do a lot of processing. Appointment scheduling probably not so much.

[cellio]

Hard to say -- doesn't I/O involve a lot of in-memory buffering too? I don't know a lot about the low-level details of reads and writes.

[madfilkentist]

Yes, but generally the channel's data rate is the limiting factor.

[mdlbear]

Actually, it's more likely to be the other way around: the thing that's going to slow down the most is system calls. If the program is doing a lot of number crunching, it won't slow down. If it spends most of its time waiting on slow input devices like the keyboard and mouse, the slowdown probably won't be noticeable (I haven't noticed any slowdown). Programs that do a lot of disk or network access, especially databases, will suffer the most. And even that will probably be handled by scaling the back end -- any retail business that can handle Black Friday will add one or two more servers and you'll never notice.

[eub]

Yep, any system built on a pool of computers can scale that, though I have to imagine there must be interesting discussions between companies and their lawyers about "your design just lost us X% of the compute we bought, please pay us X% + Y% for our trouble."

I wonder what embedded systems operators are going to do. Most embedded systems don't intend to have execution of untrusted code, which is not to say it can't be made to happen. I would guess that most embedded system either have no notion of processes and inter-process protection (the bare-metal approach, used to be common), or they run an OS but it's not likely to be free of root holes.

[mdlbear]

These days most embedded systems are running Linux unless they have hard real-time requirements. Even the ones running Linux are going to be difficult or impossible to upgrade.

That said, comparatively few embedded systems are running on vulnerable hardware; they're mostly going for low power rather than high speed, and going superscalar requires a lot of extra logic.