If Mitigations Weren't Already Bad Enough: Slow Build Times Now Lead To An Unoptimized Intel LVI Pass

[angrypie]

They should make crime illegal so no crimes ever happen.

Lulz. A Brazilian minister proposed a bill exactly like that.

[hotaru]

The only thing stolen from me is the desire to have an intel cpu.

Next year: Massive new vulnerability discovered that only affects intel but don't worry, we've got a patch that knocks another 10% off lol

and all the people who keep buying Intel CPUs will be glad it's not 97% again.

[JustRob]

We are at the point where we need to buy extra cores to check the checks and fix the fixes, along with the need for intrusion and virus detection we're looking to see if we've shot ourselves in the foot; only to discover months to decades later that it was the case.

[zyxxel]

What about the environmental impact of having to use more power to make up for all this slowdown? I'm not talking about desktop users, but servers and "clouds".

Intel is actually going to benefit from this in the short term. More demand for them...

It isn't just the servers - desktop machines also have a very big variability in power depending on load. And computers are the reason for quite a number of nuclear reactors around the world. And a couple of them can be blamed on M$. So in a Wintel system, I can see why Intel have seen a need to take up the fight on who can waste more energy - M$ or Intel.

[zyxxel]

Why do most of us care about these mitigations? It matters on virtual servers, but the only place that should run untrusted code on a desktop is the browser. If you're running untrusted native code you've already lost. Just denying javascript access to multiple threads and high resolution timers should be enough for most users, there's no need to totally wreck system performance.

Most systems runs "untrusted code". It's just a question of how untrusted it is.

If I download a music player, I expect that player to be limited to the access rights of my account. But with the type of CPU vulnerabilities we are talking about here, that music player can gain access to admin rights even if I'm not logged in as administrator.

And if your child downloads a game and runs on the childs account, that game can gain access to information only other accounts on the machine should have access to.

If I install a web server to my Linux system, I probably configure it to run as user "http" or maybe "www" or similar. And expect it to be limited to the access rights of this account. But the vulnerabilities allows that web server to listen in on other things happening on the machine.

So it's a way bigger problem than just how it affects virtual machines in cloud servers. It breaks all normal access control mechanisms your operating system has to separate different account rights.

[patstew]

If I download a music player, I expect that player to be limited to the access rights of my account. But with the type of CPU vulnerabilities we are talking about here, that music player can gain access to admin rights even if I'm not logged in as administrator.

This music player can already exfiltrate all your files, change your PATH to replace any binary it likes, read the memory of your processes and log your keystrokes/other activity. Who cares if it can read 100 bits of kernel memory given a few hours of 100% CPU usage? Also, as far as I know nobody has demonstrated a privilege escalation based on spectre etc, but local privilege escalations do pop up in linux fairly regularly. You can't safely run untrusted code, these mitigations are like fitting bars over all your windows while the front door is left unlocked.

And if your child downloads a game and runs on the childs account, that game can gain access to information only other accounts on the machine should have access to.

These vulnerabilities mainly give you a few bits from another running process. I bet most desktops only have one user account that's regularly used, and practically none have multiple people using them simultaneously.

If I install a web server to my Linux system, I probably configure it to run as user "http" or maybe "www" or similar. And expect it to be limited to the access rights of this account. But the vulnerabilities allows that web server to listen in on other things happening on the machine.

Don't run a web server connected to the internet on your desktop. If you're concerned that server might get hacked sufficiently to run arbitrary code on your computer, you should be equally concerned that the hacker knows a local privilege escalation hack too.

[zyxxel]

This music player can already exfiltrate all your files, change your PATH to replace any binary it likes, read the memory of your processes and log your keystrokes/other activity. Who cares if it can read 100 bits of kernel memory given a few hours of 100% CPU usage? Also, as far as I know nobody has demonstrated a privilege escalation based on spectre etc, but local privilege escalations do pop up in linux fairly regularly. You can't safely run untrusted code, these mitigations are like fitting bars over all your windows while the front door is left unlocked.

These vulnerabilities mainly give you a few bits from another running process. I bet most desktops only have one user account that's regularly used, and practically none have multiple people using them simultaneously.

Don't run a web server connected to the internet on your desktop. If you're concerned that server might get hacked sufficiently to run arbitrary code on your computer, you should be equally concerned that the hacker knows a local privilege escalation hack too.

I think you missed something. This music player should be limited to the account rights of my account. But the vulnerabilities means the music player can read data from other accounts that I shouldn't have access to.

Even if the machine have a single account, it still runs lots of programs that aren't run as my account - just that Windows defaults to only show the current users processes. But many of the other processes runs at a higher access right - unless I'm fool enough to always run a Windows machine as administrator.

Next thing - you lock yourself into too narrow details, thinking with your view on my comment about a web server. Lots of people have home NAS hardware. And that NAS hardware have plugin support allowing it to run databases, media scrubbers etc. And these are often run as individual user accounts. And lots of NAS supports docker.

[patstew]

I think you missed something. This music player should be limited to the account rights of my account. But the vulnerabilities means the music player can read data from other accounts that I shouldn't have access to.

Even if the machine have a single account, it still runs lots of programs that aren't run as my account - just that Windows defaults to only show the current users processes. But many of the other processes runs at a higher access right - unless I'm fool enough to always run a Windows machine as administrator.

Next thing - you lock yourself into too narrow details, thinking with your view on my comment about a web server. Lots of people have home NAS hardware. And that NAS hardware have plugin support allowing it to run databases, media scrubbers etc. And these are often run as individual user accounts. And lots of NAS supports docker.

As I said, AFAIK there isn't a demonstrated privilege escalation hack built on Spectre & co, so they don't automatically give you access to other accounts. They only allow you to read extremely small amounts of data from concurrently running processes. That threat is insignificant on most desktops where all the valuable stuff is directly accessible to the main user anyway.
Linux user accounts are a good way to isolate non-malicious processes and users, but it's not sufficient for security. If it were virtualization wouldn't be nearly as big, hosting companies would sell you a user account with shell access on a server instead of a VPS. They don't, because those servers would get hacked instantly.

[Alex/AT]

Actually, each such a massive vulnerability should lead to hardware recall & replace. This will also teach a thing or two about having some care designing hardware. Automotive vendors recall their vehicles when they are dangerously buggy, should be extended to CPU vendors as well.

[zyxxel]

As I said, AFAIK there isn't a demonstrated privilege escalation hack built on Spectre & co, so they don't automatically give you access to other accounts. They only allow you to read extremely small amounts of data from concurrently running processes. That threat is insignificant on most desktops where all the valuable stuff is directly accessible to the main user anyway.
Linux user accounts are a good way to isolate non-malicious processes and users, but it's not sufficient for security. If it were virtualization wouldn't be nearly as big, hosting companies would sell you a user account with shell access on a server instead of a VPS. They don't, because those servers would get hacked instantly.

Nothing gives "automatic access" - and neither have I made such a claim. But any real OS will concurrently run both system processes and end-user processes. Which means that data extracted from the memory space of these processes can leak important information that can later be used to escalate access rights - the ability to do so is exactly the same as if talking about virtual machines in a cloud hosting centre.

One example is the process handling your login. A process that, when handling a login request is accessing files a normal user shouldn't normally see. If taking a Linux system, the login process will read the /etc/shadow file - a file that normal users aren't allowed to read and the reason why password hashes are no longer stored in the publicly readable /etc/password file.

It isn't true that all valuable information is directly accessible to the main user. Look at registry hives for example on Windows machines - a normal user can't normally read all files on the system drive. But a processes running with backup privileges can read information you are blocked from reading. And while backup programs aren't run 24x7 they are run now and then - and often at known times.

Virtualization is way more than increasing security - it has very much also to do with isolation of environments, to allow a virtual machine or a docker container to be moved from one host (or cloud supplier) to another without having to know anything about the host machine itself. For security, Linux CGROUPS with a normal account gets you just as far - it's basically the tool used when creating Docker support on a cloud server.

In the end, the threat is directly related to the economic gain. And the normal desktop/laptop machine isn't just a machine for a home user - it's also what all hospitals, governments, ... are using to give their employees computer access. So there is a strong economic incentive to look for ways to break out of normal end-user access rights in the exact same way as there are economic incentives to try to access data from other virtual machines.

So while there is a basically zero incentive to hunt a specific home user, the OS vendors needs to take into account that some of their installations will be run by users who do run their computers in organizations where it's possible to demand huge amounts of ransom money. And more than one of the nation-state attack routes have over the years managed to leak out into the common domain and be available even in "script kiddie" tool boxes.

In short - don't argue about security based on already documented attacks. It's not them that are the main threat. It's the attacks that are currently been developed - the flawed machines will not go away in a good many years.