CPU Usage Differences After Applying Meltdown Patch at Epic Games

Post by walshemj » Sat, Jan 06, 2018, 5:41 PM UTC

djsumdog wrote: post #213

forgotpw2018 wrote: post #153

Earlier quoted context omitted.

Intel's PR dept is in overdrive, but the truth about this vulnerability is that it's essentially worst-case. It really only affects workloads where high performance is important. The average user might not see an impact but if you need fast IO God help you. The solution is to 'make less syscalls' but the problem is that syscalls have always been slow and the people making a lot of them are only doing so because they…

I wonder if we'll start seeing more userspace storage drivers because of this. If anything, for big shops like this one, I wouldn't be surprised if we saw a move away from hosted providers (the "cloud" .. god I still hate it when people use that word), and return to co-located setups. At least for people who need immediately performance needs, AMD might make a lot of short term sales right now.

Post by forgotpw2018 » Sat, Jan 06, 2018, 5:43 PM UTC

mistercow wrote: post #215

[deleted] wrote: post #178

Earlier quoted context omitted.

[deleted]

Is that remotely feasible? You're basically suggesting that Intel needs to refund or replace every PC and server CPU they've sold in the last five years. The fdiv recall cost Intel almost half a billion dollars, and that was for a small subset of processors that most people didn't replace. Intel has a lot of assets, but replacing five years worth of CPUs might actually bankrupt them.

Post by bonzini » Sat, Jan 06, 2018, 5:45 PM UTC

yborg wrote: post #207

bonzini wrote: post #187

Earlier quoted context omitted.

What is the other way round? (I worked on the fixes for Red Hat).

I think he's saying that unpatched, a co-resident VM can compromise the host even if you are locally patched. If the host is patched this doesn't matter (for VM escapes); however, for those on public clouds that will apply the host patching globally, you will be eating the performance degradation whether or not your workload cares about it. I don't think AWS et al will be offering a "run unpatched instance" option. O…

Post by wyager » Sat, Jan 06, 2018, 5:46 PM UTC

djsumdog wrote: post #210

serf wrote: post #185

Earlier quoted context omitted.

>They acted in good faith. That's new for a company, and it's not indicated by their PR spin right now. What I think happened : a company produced a product with a problem. Probably not out of malice, but ignorance. One of two things happened after, which can kill the 'good faith' argument ; the problem was found internally and hushed, or the problem was found externally and minimized to reduce financial burden arisi…

Well this type of attack has been theoretical for years. The Project Zero referenced some papers from the mid-2000s that talked about it. But the implementation, even today, isn't exactly trivial. Modern processors are insanely complex systems. Branch prediction, out of order execution, hardware virtual memory management, hardware virtualization, etc. Not to mention that these are side-channel attacks. It's not a dir…

Post by ufo » Sat, Jan 06, 2018, 5:55 PM UTC

etatoby wrote: post #202

jameshart wrote: post #140

Earlier quoted context omitted.

If you're talking about a game server like this, though, where you don't have sandboxes running client-originated code, just processes running your own software, any remote code execution vulnerability is already going to be in a position to do incredible damage. There are almost certainly going to be other privilege escalations available to you once you've buffer-overflowed or whatever to dupe the server into runnin…

Can any of this be exploited from Javascript? That would be a humongous can of worms.