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

41–50 of 296 posts

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

#41

Post by ZenoArrow »

lrem wrote: post #28
ZenoArrow wrote: post #9

Earlier quoted context omitted.

Modern consoles now come with web browsers, and the researchers proved that the attacks could be performed via web browsers, did they not?

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 make it still appear like it came from a trusted domain.

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

#42

Post by Asdfbla »

rocqua wrote: post #35
lsd5you wrote: post #4

Earlier quoted context omitted.

Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?

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 time (for your typical cloud computing provider)?

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

#44

Post by mmaunder »

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.

Guess that's what I meant, but I'll take either!

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

#45

Post by Asdfbla »

s_kilk wrote: post #7
lsd5you wrote: post #4

Earlier quoted context omitted.

Not entirely sure why we need to update/protect most servers, since generally they won't be running untrusted code, right?

If they're operating on data supplied by the attacker, they're potentially a single hop away from executing untrusted code.

Would be funny to see a game server exploit (since this was about Epic Games here) via specially crafted network packages that look like valid game messages. Has this happened before? Seems natural that those game coordinator backends and such should have security holes too.

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

#46

Post by TrickyRick »

canpan wrote: post #38
nicolaslem wrote: post #13

Earlier quoted context omitted.

I wouldn't be so sure of that. They at least run Javascript through their web browser.

The Nintendo Switch generally only allows white-listed pages. So the attack vector is pretty small. The other consoles, yes, should be possible. But I think not too many people use their consoles for browsing.

It will show any captive WiFi-portal however so perhaps watch out for that.

In addition they do have a store with indie games which seems to be more or less open to anyone (I assume there are some checks but I wouldn't trust them completely) much like Steam.

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

#47

Post by _wmd »

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);

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

#49

Post by pdpi »

dagss wrote: post #10
s_kilk wrote: post #7

Earlier quoted context omitted.

If they're operating on data supplied by the attacker, they're potentially a single hop away from executing untrusted code.

...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.

If you’re running an SSL terminating web server in front of your application server (on the same node), these exploits would allow you to read the ssh private key from the front end, AIUI.

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

#50

Post by TrickyRick »

transpostmeta wrote: post #23
aceoflolo wrote: post #22

>We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates. So they are saying "you can't log in because we're too cheap to rent more servers now that this pat…

Resolving scalability issues is not as simple as "rent more servers".

Renting beefier servers may also be an option if the performance impact scales linearly with pre-patch performance. However it's not clear in this case how that works.
Post reply on HN