Spectre chip security vulnerability strikes again; patches incoming | Hacker News Reader

Spectre chip security vulnerability strikes again; patches incoming

zdnet.com

34 pointsCrankyBear26 comments

previous discussion: https://news.ycombinator.com/item?id=17121811 (172 points by brandon 19 hours ago | 20 comments)

It's not a dupe. This article gathers up info from multiple and later sources--Intel, Red Hat, etc. and how to deal with it--not simply the first mention of the problem.

These performance regressions are getting a bit depressing.

Is there some other way we could architect chips or operating systems that would allow these branch predictors to go full bore instead of having to hamstring them? When this story first broke I know we talked a bit about the impetus to move code out of the kernel into user land.

We could have shorter pipelines ;)

Which would hamstring performance.

yeah. it was a half-joke + half-serious. Would be interesting to see the performance of branch predictor fix vs just having a short pipe.

Shorter pipelines don't fundamentally change anything about speculative vulnerabilities. Longer pipelines allow faster clock rates, but that is not the problem here. Speculative vulnerabilities are because branch prediction is needed to get the CPU looking far enough in the future to feed all the functional units so that it can execute not just one instruction per clock, but 4 (actually u-ops, but you get the picture). To do that, you need to know the execution path far into the future. That is not really related to the pipeline depth at all.

Well yeah, but the implied point is that there must be some depth and workload where having a branch predictor fast or slow makes much less difference.

Well, 'lots of simple cores' is potentially one answer - but it does require you to have the type of workload that can work well heavily threaded. Similarly, CPUs that are heavily threaded rather than speculative, i.e. they don't mind stalling because they have lots of other threads they can switch to.

Switching (or indexing) predictor state on task and privilege level.

That is not granular enough, since language runtimes have assumed up until Spectre that enforcing security with safety checks inserted into compiled code was enough. With these side channels it is not.

It's even more complex. It's not only the predictor state that would need switching/indexing, it's the result of any prediction.

A speculative load in cache is global today, and that leads to a possible side channel attack. One may think about marking a speculatively cached entry by its security context, the only context allowed to "see" it until the speculation is resolved. But that is not enough: the entry may have evicted another, and that's globally visible. Or one may not use the regular caches, but add another lookup structure (CAM) for in-fly speculative loads (and same for store), indexed by context.

Another source of complexity is: what is a security context? An OS could use existing structures like processes, and it makes sense, but it's not enough. For a sandboxed application a given process or thread could run untrusted sandboxed code (Javascript) and also trusted runtime. In this case, the application need to help and manage security contexts. It's possible, but not backward compatible.

I expect progress will be made, but considering the complexity/costs it may take some time...

> It's even more complex.

Oh, this one goes elbows, armpits, neck, ten thousand fathoms deep. Now just imagine that every memory access that the processor does actually consumes another type of resource, which is memory bandwidth. There are a limited number of cache-fill lines and those can be occupied or not; after tracking down all of the state of things at rest, you now have to think about the information leakage from the occupancy of the various networks of the CPU--data in flight. Tougher to analyze, but also tougher to secure.

It's gonna be separate CPUs, memory busses, and disks if we really want to get rid of side-channels.

And that's actually simple. Simple is better for security!

Wouldn't this mean that kernel calls are interprocess communication?

In general, yes. But one could, e.g. have a second kernel, or some microkernel subsystems, running on the other system for the most common calls. In fact, that'd be even safer.

It'd be safest to have a whole machine per process :)

I hope there's a way for users to disable these patches. I for one would rather have a fast processor that does speculative execution than one that takes a significant N% performance hit but is armored against speculative attacks.

Security compliance is becoming more and more like a ball and chain shackled to our legs. I expect security to slowly eat up a bigger and bigger share of processing power which translates to more sluggish chips, more sluggish software, etc.

Hi, could you please explain this further? I always assumed that if a program or chip is vulnerable then it is not operating as intended and must be patched quickly. You’re suggesting that if a security vulnerability is patched and it removes a feature (in this case, processor performance) we should forgo it. Am I understanding correctly?

I think the point is that "security" isn't absolute, its always relative to some threat model. But if untrusted code isn't a part of your threat model then you might prefer the performance benefits.

The vulnerability allows a user process to see data from the kernel, which could let it take over the machine. That's a huge problem on a multi-user machine, but not on dedicated servers that only run code the owner wants to run.

I don't really care about malicious user-mode applications being able to take a peek at kernel memory on my desktop machine, because there are effectively two users: me, who often becomes root locally and remotely, and root. I do care about random websites being able to do the same (obviously).

Due to "Linux security properties" any random user-mode application is me and therefore already root and does not require an exploit to read kernel memory. The user-root-distinction is all but the thinnest of veils on a desktop Linux.

I disagree — security is a sina qua non for a functioning system. Leaking information between different processes is simply incorrect, even on a single-use system.

For systems where you can guarantee that no untrusted code runs I'd rather have the faster processor.

Linux actually applies a mitigation that is applied for sandboxed processes only by default to mitigate Variant 4.

For Variant 3A, well, it's another Meltdown and will be handled as such.

Sure — security is, in abstract, important. The security requirements of different systems vary, though.

I'm much more worried about things like this in edge machines that talk to the public than some backend data-processing pipeline that doesn't talk to the outside world at all.

At least AMD recommends you don't need the patch:

>"Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.

We have not identified any AMD x86 products susceptible to the Variant 3a vulnerability in our analysis to-date." https://www.amd.com/en/corporate/security-updates

I couldn't (quickly) find a similar comment from intel.

In the Linux kernel, the mitigation is applied for sandboxed processes, which makes sense.

Note that no microcode updates are needed for AMD, while they're needed for Intel.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Reply on news.ycombinator.com