CPU Usage Differences After Applying Meltdown Patch at Epic Games • Hacker News Board

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#201

Post by rdtsc » Sat, Jan 06, 2018, 5:15 PM UTC

metaobject wrote: post #148

Filligree wrote: post #142

Earlier quoted context omitted.

More than a doubling of CPU use, but for consistency's sake: The other percentages we've been offered have been in terms of performance reduction. We were told to expect a range of 5-30%; this is about 60%. Somewhere a sysadmin's hair has started smoldering.

I’d go farther, anybody who is concerned with application performance may soon see/smell their hair smoldering. We write a lot of code that needs to run as fast as possible (processing, post-processing, generating real-time weather/satellite data) and I’m concerned about time windows and whether we’ll be able to meet requirements.

For pure computational cases Meltdown vulnerability remediation might not impact you as much. Meltdown fixes would affect applications that do a lot of syscalls - lots of socket IO, IPC stuff, small and frequent disk IO ops etc.

You'll probably see a wide variety of benchmark results anything from no impact to things like above. So just make sure you measure carefully with your own workload.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#202

Post by etatoby » Sat, Jan 06, 2018, 5:16 PM UTC

jameshart wrote: post #140

progval wrote: post #82

Earlier quoted context omitted.

It makes sense if you don't want a remote code execution in one of your app to provide a full root shell.

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.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#203

Post by AFNobody » Sat, Jan 06, 2018, 5:16 PM UTC

jimmaswell wrote: post #189

dk1138 wrote: post #175

Earlier quoted context omitted.

If you bought a car that needed to go 60mph and a subsequent update to the car from the manufacturer for safety meant it could only go 30mph, there would be legal consequences. Of course you can't predict every contingency, but some of them you pay for.

Did Intel ever specifically 100% promise a certain performance in their advertising? Do they have contracts having such promises in them with vendors?

> Did Intel ever specifically 100% promise a certain performance in their advertising?

Yes.

They showcased benchmarks and paid people to benchmark/review their product along similar lines.

https://ark.intel.com/products/96900/Intel-Xeon-Processor-E7...

etc.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#204

Post by kazagistar » Sat, Jan 06, 2018, 5:18 PM UTC

merb wrote: post #156

if people would still use good old owned hardware without any virtualizsation, spectre and meltdown would not be as scary as it really is on server hardware. which means that only clients would be affected. but since everything runs on the cloud, we basically need to update the whole world.

It's still pretty scary to have computers where all of memory is readabe from every process, even if you own them.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#205

Post by kazagistar » Sat, Jan 06, 2018, 5:23 PM UTC

flusteredpie wrote: post #33

ZenoArrow wrote: post #29

Earlier quoted context omitted.

> "What console of the current generation comes with an Intel CPU?" The Switch appears to be based on ARM cores that are vulnerable.

Will this aid homebrew communities in their efforts to run unsigned code on the PS4, xbone, Switch et al?

I suspect not, but I could see it used to discover future vulnerabilities. Read access to all of memory is pretty powerful.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#206

Post by rdtsc » Sat, Jan 06, 2018, 5:24 PM UTC

sillysaurus3 wrote: post #168

forgotpw2018 wrote: post #132

Huge real world performance impact, they didn't say how much but it looks like close to 100%. I smell a class action lawsuit coming.

Hopefully not. Lawsuits are a fine way to stifle innovation. Imagine how hard it would be to push through any idea at Intel. No one saw this coming. Things happen. It's impossible to predict every contingency. They acted in good faith. Also, heh, users are funny: "all other games i have work fin by the way so there must be a problem whit fortnite."

> Things happen. It's impossible to predict every contingency.

Normally I'd agree but not in this case. Notice that besides latest ARM it seems no other architecture is susceptible to Meltdown - s390x, SPARC, POWER, AMD etc.

Speculatively loading and executing code across protection boundary is something someone should have thought twice about. Doesn't mean other vendors knew or had PoC examples, but they could have had an instinctive hunch.

I've given this example before, say I have some sensitive data on a server. I could install a bunch of services and API endpoints on it, to access it faster, inspect it, extract it various formats etc. Or I could decide to lock it down and just install only the minimum number of needed things, locked everything down. Doesn't mean I knew all those additional APIs or services had vulnerabilities, but it's just a good practice.

If the server gets hacked and someone looks back, I think they would be justified asking "What the hell were you thinking installing all that crap you didn't need on it".

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#207

Post by yborg » Sat, Jan 06, 2018, 5:25 PM UTC

bonzini wrote: post #187

mwarkentin wrote: post #161

Earlier quoted context omitted.

I think it’s the other way around.. and the host updates are what have been introducing these performance hits as well.

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. Or maybe they will, this looks pretty devastating for some workloads; on the other hand, cloud providers could actually end up making a lot of money from this issue...

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#208

Post by [deleted] » Sat, Jan 06, 2018, 5:25 PM UTC

nudgeee wrote: post #170

forgotpw2018 wrote: post #132

Huge real world performance impact, they didn't say how much but it looks like close to 100%. I smell a class action lawsuit coming.

I think CPU designers are getting too much flak for this. The side effects of speculative execution has been around ever since their introduction. A compounding problem is how abstract software has become, it has made assumptions on the underlying execution model without a deeper understanding of its sublteties (sandboxing, containers, etc trying to guarantee process isolation). It’s the Law of Leaky Abstractions [0]…

[deleted]

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#209

Post by [deleted] » Sat, Jan 06, 2018, 5:26 PM UTC

_wmd wrote: post #95

jacquesm wrote: post #69

Earlier quoted context omitted.

That only works if messages are independent of answers received and are all known at the same point in time. In most games this typically would not be the case, you'd use a message to cram as much state change into it as is known to keep the game moving fluidly. Packing more than one such message together would serve no purpose.

I'd have presumed otherwise, but I'm not sure if you're understanding the API correctly.. it's not about sending multiple messages to the same destination, but to multiple destinations in a single call. The msg_hdr struct has room for specifying the target address. From userspace' perspective, even if the same data isn't being broadcast at every client, just building up a big array (perhaps while looping over the inp…

[deleted]

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#210

Post by djsumdog » Sat, Jan 06, 2018, 5:27 PM UTC

serf wrote: post #185

sillysaurus3 wrote: post #168

Earlier quoted context omitted.

Hopefully not. Lawsuits are a fine way to stifle innovation. Imagine how hard it would be to push through any idea at Intel. No one saw this coming. Things happen. It's impossible to predict every contingency. They acted in good faith. Also, heh, users are funny: "all other games i have work fin by the way so there must be a problem whit fortnite."

>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 direct vulnerability, it requires executing some code and measuring timing very precisely; similar to and oscilloscope and a very expensive safe.

Of course Intel is going to be spinning this however they can for damage control. That's what PR departments do. I still doubt engineers at Intel really thought this attack was plausible, or else they wouldn't have been engineering chips this way for the past decade.