Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CPU Usage Differences After Applying Meltdown Patch at Epic Games

epicgames.com

Post reply on HN
Print view View original

61–70 of 296 posts

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

#61

Post by lrem »

ZenoArrow wrote: post #41
lrem wrote: post #28

Earlier quoted context omitted.

Next patch: we enhanced your security by disabling execution of JavaScript from untrusted domains. In unrelated news, we now block ads!

If they are going to block JavaScript, they need to do it for all domains, not just untrusted domains. For example, if I can MITM my own website activity (which I can, by having a device that sits between a router and a console), then I can change the JavaScript coming from trusted domains. In other words, if I visit a site like Google or Facebook on an affected device, I can change the JavaScript that is run, and ma…

There are dozens of ways to prevent this, viable because you fully control the hardware and software stack of the terminal (and only allow contacting servers of your choosing).

I imagine they are more concerned about game authors snooping keys or whatnot.

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

#62

Post by tgb »

contrarian_ wrote: post #21

Pretty much what I predicted here: https://news.ycombinator.com/item?id=16054674 > Sounds like servers handling lots of small UDP packets would be hit pretty hard.

Since they describe this as log-in issues, should we expect that to be a server using lots of UDP? Or do you think that the log-in service is hemmed in by the load on the game servers?

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

#63

Post by viraptor »

I know they don't have to share the details, but the "patched" part is not really clear. Did they update to a new image / more recent kernel / anything else? Much like the redis post linked in HN before, we don't know if the impact is because of the "pti turned off/on" change, or are there more moving parts involved.

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

#64

Post by yorwba »

chrisper wrote: post #14
dagss wrote: post #10

Earlier quoted context omitted.

...at which point that untrusted code gains full access to the only userspace process that matters on that node. If you gain access to run code on a server process why escalate further, you already have access to everything that matters?... Assuming bare metal. In shared hosting / cloud / VMs it is different.

With Meltdown / Spectre you can break out of sandboxes as far as I understand.

That only matters if not everything is in the same sandbox. Many non-cloud servers probably either only run a single service, or they run all processes as the same user, which means that a sandbox escape doesn't really matter. You can't lose any security layers you never had in the first place.

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

#65

Post by asheldon »

Asdfbla wrote: post #42
rocqua wrote: post #35

Earlier quoted context omitted.

The replies are missing something from the original article. They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.

I suppose if a Cloud provider could ensure that all your VM instances run on the same host and no other VM is allowed there then the issue would be a bit mitigated. Although this restriction on how the cloud provider is allowed to schedule your VMs probably would somewhat defeat the point of cloud hosting in the first place. Out of curiosity, how many VM/container instances usually run on a physical host at any given…

AWS provides the ability to guarantee you don't share physical hardware with other customers with "EC2 Dedicated Instances" (https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...). I'm not familiar enough with other cloud provider offerings to say if they do or do not have similar features.

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

#67

Post by Thiez »

ZenoArrow wrote: post #41
lrem wrote: post #28

Earlier quoted context omitted.

Next patch: we enhanced your security by disabling execution of JavaScript from untrusted domains. In unrelated news, we now block ads!

If they are going to block JavaScript, they need to do it for all domains, not just untrusted domains. For example, if I can MITM my own website activity (which I can, by having a device that sits between a router and a console), then I can change the JavaScript coming from trusted domains. In other words, if I visit a site like Google or Facebook on an affected device, I can change the JavaScript that is run, and ma…

You can't just mitm when the JavaScript is served over https, unless you also can install your own certificates on the machine you're trying to hack. But when you have permissions to install new certificates you probably don't need the hack in the first place.

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

#68

Post by Fargren »

Asdfbla wrote: post #42
rocqua wrote: post #35

Earlier quoted context omitted.

The replies are missing something from the original article. They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.

I suppose if a Cloud provider could ensure that all your VM instances run on the same host and no other VM is allowed there then the issue would be a bit mitigated. Although this restriction on how the cloud provider is allowed to schedule your VMs probably would somewhat defeat the point of cloud hosting in the first place. Out of curiosity, how many VM/container instances usually run on a physical host at any given…

With AWS, and I assume most other cloud computing providers, you can pay extra for you instances to run in a host without someone else's VMs. You probably should be doing this for any servers were you handle sensitive data, but it is a place were many will be cutting corners.

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

#69

Post by jacquesm »

_wmd wrote: post #47
contrarian_ wrote: post #21

Pretty much what I predicted here: https://news.ycombinator.com/item?id=16054674 > Sounds like servers handling lots of small UDP packets would be hit pretty hard.

There's potential for a little rearchitecting to help, at least in the case of UDP: NAME sendmmsg - send multiple messages on a socket SYNOPSIS #define _GNU_SOURCE /* See feature_test_macros(7) */ #include int sendmmsg(int sockfd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags);

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.

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

#70

Post by jacquesm »

chrisseaton wrote: post #43
mmaunder wrote: post #39

Post. More. Benchmarks. I'll do the same once I have them. More data on this across platforms and apps is incredibly helpful for all.

Real data like this post are more useful than more benchmarks.

They are benchmarks, just not microbenchmarks. Actual application performance is the gold standard for benchmarks.

https://en.wikipedia.org/wiki/Benchmark_(computing)#Types_of...

Post reply on HN