AMD Inception Mitigations Cause 20% Performance Drop in Database Servers | Hacker News Reader

AMD Inception Mitigations Cause 20% Performance Drop in Database Servers

phoronix.com

101 pointsnitinreddy8827 comments

Unfortunate, but I guess it's a bit like how safety regulations make building slower but we accept it for the far, far fewer workers dying or being maimed in accidents...

Is this Inception issue the kind of thing that can be solved more efficiently in silicon with future generations, or is the mitigation something we have to accept and just go for faster processors to make up for it in the future?

I'm not familiar with this specific mitigation, but aren't they often only need in multi user environments?

Meaning if you have a dedicated machine for your database, you probably don't want to turn these on. i.e. it's good to know that this is something you probably don't want.

Your web browser is a multiuser environment with no access control.

Yes, but the scenario was

>> if you have a dedicated machine for your database

That's not a machine with a browser. The game then becomes: can somebody "inject" this sort of attack through a database connection. Good practice should insulate you but who knows.

Even in that scenario it’s normal to run the database as a non-root user. This is important so that if there’s a database escape vulnerability, some sort of RCE, then the attacker doesn’t have full control over the machine and would still need another privilege escalation path to do the most damage.

You could skip this and run the DB as root, but that’s a big security trade off that most users shouldn’t be taking.

That's not really a practical issue in most cases. In almost every situation if you attack the database host, there's nothing apart from the database running there. Once you control the database you have full data access already. You'll potentially need to escalate to enable outbound network access if it's restricted on the host rather than network layer, but even that's not common. For large databases you're more likely to get more access by changing trusted serialised data, or inject some commands where possible.

Having access to a restricted database user may well not grant access to all data, but being able to escape to the root system user could mean free access to the data reading it directly off disk.

Root access also provides many more opportunities for persistence. Most attackers don't want to be discovered, they want to remain and continue to exfiltrate. Exfiltration out-of-band will also be easier as root as you would be able to modify the firewall.

Root may be a little less useful on a cloud VM where there is cloud level network isolation etc, but it's still a Bad Idea.

Apologies if I ask a stupid question: is it necessary to run the mitigations on a database server?

And even better: can we disable the mitigations while still keeping up to date with patches and BIOS updates?

If that database server is a VM (cloud host or on-prem), the host will likely decide to have mitigations on.

If the database server gives shell to DBAs or such who don't get root, perhaps yes.

If the owners wish to restrict the attack surface of most of the non-database software running on a current day fat linux distro, perhaps yes. No mitigations means buffer overflow in any network-exposed code (DHCP client, DNS resolver, SSH server, Prometheus metrics exporter, ...) could lead to a ransomware attack on the database etc.

Other workloads with noticeable performance hits (at least relevant to my day to day work):

* Code compilation - Linux kernel compilation takes ~15% longer with any of the mitigations on. LLVM and Node compilation are less substantial for kernel only, or safe RET microcode fix, but still ~15% longer for the IBPD mitigation. Though the Linux kernel gap seems much smaller (~7%) when tested on desktop ryzen (zen 4) instead of EPYC (zen 3)

* Numpy benchmark - at least ~10% loss with mitigations (on EPYC)

* nginx - at least ~15% with loss with mitigations (on EPYC)

Most other impacts limited to less than 5% (if any).

Too bad https://make-linux-fast-again.com/ isn't loading anymore. Anyone knows an up to date guide for disabling all mitigations? I found https://gist.github.com/jfeilbach/f06bb8408626383a083f68276f... but it was last updated in March (?).

Also is there an equivalent for Windows?

> Anyone knows an up to date guide for disabling all mitigations?

IIUC, mitigations=off should disable them all. No need to specify them one by one and keep track of all of them.

Of course, I'm not recommending this, and you should only do it if you know what you are doing.

The official docs contain it: Linux: https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa... (see the mitigations option)

Related story (5 days ago)

"Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show": https://news.ycombinator.com/item?id=37085043

I discovered this myself yesterday. I suddenly saw a drop in performance after an update and ran a phoronix benchmark I have been running to see results from my overclock. I got a 5s (~8% ) increase in timed Linux kernel compilation.

I turned mitigations off and was back to normal. I was going to try to figure it out today, but this is probably it.

Actual title: "Benchmarking The Performance Impact To AMD Inception Mitigations"

Honest question, what are the real world impacts of these kind of vulnerabilities? If I am running a few on-premises private servers where I control all the software, should I be worried?

>I control all the software

A bold statement to make. Even if it would be true, do you control all the inputs for that software or can other people feed it with data?

If you can lock down ALL the software used & disable remote access, you'll likely never encounter this vulnerability. It requires local unprivileged access in order to be used, so if you can restrict that to a few allowed processes, you'll be 90% fine.

Do you execute any untrusted code submitted by the users? It not, then it's very likely not an issue for you.* This mostly allows escaping from a sandbox or getting elevated privileges on a host. But in those cases you're already hacked and the attacker has access to your data, so getting root on some server likely isn't a bigger deal than the initial hack.

* there's a chance that this enables a remote exploit through some specially crafted data for some popular library... the chances are very slim though

By the time the security bullies are done "fixing" my CPU, I will be able to open my start menu faster using an abacus.

Any word on impact on zen4?

Not sure if you noticed, but page 6-8 from the article are actually benchmarking results from a zen 4 (Desktop Ryzen 7950).

Completely missed it, thanks!

For M2 for that matter.

Mitigations=off is aging like fine wine.

Reply on news.ycombinator.com