Hacker News Reader

Comment by barkingcat | Hacker News Reader

The article is missing the largest elephant in the room for datacenter cpu's: the security issues Intel chips have had latent for the last decade, and the constant patching and bios updates (and re-updates as researchers discover new attacks) that are needed in order to make datacenter use sane.

Intel really messed up, and has no one to blame but themselves.

View on HN

I don't disagree generally.

But anytime there is renewed competition I wonder if the new competitors are better security wise, or just haven't been tested much yet security wise.

I hope AMD is doing better, but I'm not sure how to tell just yet. Things like the speculative execution problems seem to be a general issues inherent to speculative execution, so if AMD is doing it and they become a bigger target I would expect new issues to arise.

There are issues both in general regarding speculative execution, and also Intel Specific errors in their implementation of speculative execution.

The combined issues of these two aspects of the mistake in the theory of speculative execution as well as the implementation is what makes it so bad for Intel vs any one else on the market.

Does anyone know of any benchmarks that go through the full impacts for all of Intel’s hardware-level security issues?

I remember seeing the Linux kernel devs discussing some massive 10+% performance hits back around Meltdown/Spectre patch time, and I’m now wondering what the final impact has been.

I don't know about full pre and post benchmarks but there is the latest benchmark from Phoronix which benchmarks the latest Spectre "SWAPGS" mitigations [0].

[0]: https://www.phoronix.com/scan.php?page=article&item=swapgs-s...

10 percent? My teams RDS cpu usage spiked up by 40 percent after the initial patch [0].

[0]: https://m.imgur.com/a/khGxU

Oh wow. That's a lot worse than I'd expected. Intel really royally screwed up, especially since so much of their current optimization relies on the same hardware functionality that makes these side-channel attacks possible.

Epic Games saw their CPU usage double after applying the meltdown patch. Things have gotten quite a bit slower since then. Turns out flushing every time you switch into kernel space carries a massive impact if you are realtime with lots of network calls.

https://web.archive.org/web/20180106011413/https://www.epicg...

What is RDS short for?

Amazon web services relational database service: https://aws.amazon.com/rds/

The impacts really depend on your use case. The mitigations make each context switch have a much higher fixed cost.

If you're doing something that's syscall heavy, you're going to see a big negative difference. If it's something that's CPU heavy without making many syscalls, you're not going to see a lot of difference.

How are these relevant in a datacenter context? If you are the sole tenant of a machine then you will disable all the mitigations.

Whether or not you consider it an important part of insider threat prevention depends on too many other factors (i.e., have you already prevented other, easier avenues of attack) to generalize, but it's not unreasonable to want isolation of jobs even within a single-tenant datacenter. You may also do things like run external code in sandboxes, and you'd like that sandboxing to be safe and effective.

Google is not the sole tenant. It's running a cloud.

Sure, on a handful of their machines. But they have a lot of private and dedicated hosts, too.

Yes, but even internally, separation between departments in a company is extremely important.

Google cannot have a breach between the services running gmail and the services running adwords for example, even if those are running in the same server on an internal cloud that has strict permissions being enforced by software.

This is especially even more relevant in any kind of datacenter application, even if the company is the sole tenant, because they are working with Client Data - which is data that does not belong to Google, but to their customers.

"Google's Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines. It achieves high utilization by combining admission control, efficient task-packing, over-commitment, and machine sharing with process-level performance isolation" [0].

All of their processes run together on the same machines so you wouldn't want to risk one compromised process access data on possibly any other process.

[0]: https://ai.google/research/pubs/pub43438

You're going to make someone's life very special by having them deploy to a completely different environment than their secure workstation or build server and telling them that the security mitigations(or lack of) are causing an issue.

Reply on news.ycombinator.com