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

Spectre mitigations murder userspace performance

robert.ocallahan.org

Post reply on HN
Print view View original

231–240 of 294 posts

Re: Spectre mitigations murder userspace performance

#231

Post by kurikuri »

dijit wrote: post #14
neilsimp1 wrote: post #2

`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a... .

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

>desktop executes untrusted and rather arbitrary code pretty often

Aren’t the most affected group of users cloud users (and providers), not desktop users? I thought the biggest risk of specter attacks is the ability to glean information on other server residents who should be segmented off. There are many more concerns in user space which make attacking a desktop with specter pretty cumbersome for low reward wrt opportunity cost.

The performance savings of speculative execution do seem to be worth the risk on a desktop IMO.

Re: Spectre mitigations murder userspace performance

#232

Post by quotemstr »

emilfihlman wrote: post #174
Filligree wrote: post #47

Earlier quoted context omitted.

Do you mean io_uring?

No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done. Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if yo…

> Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace.

io_uring already gives you that. You can submit multiple operations in a batch and link the operations together so that if one operation in a chain of linked operations fails, io_uring won't try to execute the rest.

Re: Spectre mitigations murder userspace performance

#233

Post by ncann »

tyingq wrote: post #20
dijit wrote: post #14

Earlier quoted context omitted.

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

Nice 3rd party toggle for windows: https://www.grc.com/inspectre.htm Or a Powershell script from MS: https://support.microsoft.com/en-us/topic/understanding-get-...

That Powershell script seems to show the current status only, and not have any option to turn the protections on/off?

Re: Spectre mitigations murder userspace performance

#234

Post by diveanon »

ggreer wrote: post #142
mhh__ wrote: post #43

Earlier quoted context omitted.

https://leaky.page/ I don't know about the wild, but if this were tuned (i.e. this requires a lot of work for the first byte, the rest are easy) for a HVT you wouldn't know.

On my laptop's Core i5-10210U with mitigations=off, the demo just prints "[!] error: could not infer memory layout" until it runs out of retries. This is on Chromium 91.0.4472.106 and kernel 5.12.11-arch1-1. lscpu shows vulnerabilities: Itlb multihit: KVM: Mitigation: VMX disabled L1tf: Not affected Mds: Not affected Meltdown: Not affected Spec store bypass: Vulnerable Spectre v1: Vulnerable: __user pointer sanitizat…

I got the same result on a pretty similar system.

Re: Spectre mitigations murder userspace performance

#235

Post by lima »

staticassertion wrote: post #163
yyyk wrote: post #161

On the one hand, I haven't seen any real exploitation of Spectre, at least by a non-TLA. On the other hand, the mitigations aren't so slow anymore on a modern CPU: https://www.phoronix.com/scan.php?page=article&item=3-years-... IMHO, there's a good argument for turning off the mitigations on Skylake in some systems - but in modern CPUs the cost of leaving the mitigations on is bearable.

Yeah, kinda similar to rowhammer. I was just saying the other day that these exploit techniques are totally viable, but there's not much point - privesc is trivial on any desktop environment (linux or Windows, maybe less on osx), and usually not too hard on servers either. Fancy exploits aren't worth it when operating systems are so vulnerable to local attackers. That said, the mitigations are assurances, and it also…

> linux or Windows, maybe less on osx

Trivial on macOS, too.

Smartphone operating systems are better (and ChromeOS).

Re: Spectre mitigations murder userspace performance

#236

Post by dsp »

emilfihlman wrote: post #174
Filligree wrote: post #47

Earlier quoted context omitted.

Do you mean io_uring?

No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done. Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if yo…

> having the kernel execute consecutive systemcalls without switching the context

io_uring enables exactly this

https://kernel.dk/io_uring.pdf

Re: Spectre mitigations murder userspace performance

#237

Post by [deleted] »

PedroBatista wrote: post #96
jfrunyon wrote: post #93

Here's the lesson: we hit the ceiling on our current technology a while ago. Developers continue to behave as though computing resources will continue growing as they used to, even though they've been stagnant for years.

That's not really true. I think your views are founded on the "moar Mhz moar performance" myth ( which is prevalent ), and Intel's decades old monopoly didn't help either, but if you compare 2 equivalent CPU's 10-15 years apart, there is no stagnation in performance. Maybe the old trick of cranking up the Mhz and call it a day doesn't work the way it used to, but in terms of performance results we are getting improve…

[deleted]

Re: Spectre mitigations murder userspace performance

#238

Post by foobarbazetc »

kurikuri wrote: post #231
dijit wrote: post #14

Earlier quoted context omitted.

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

>desktop executes untrusted and rather arbitrary code pretty often Aren’t the most affected group of users cloud users (and providers), not desktop users? I thought the biggest risk of specter attacks is the ability to glean information on other server residents who should be segmented off. There are many more concerns in user space which make attacking a desktop with specter pretty cumbersome for low reward wrt oppo…

Yeah, this is mostly an issue in the cloud where you share SMT threads with other people.

Re: Spectre mitigations murder userspace performance

#239

Post by nyanpasu64 »

titzer wrote: post #57
FunnyLookinHat wrote: post #4

Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients. I'm a foil hat as much as the next - securi…

Mitigations for inter-process side channels address the issue of local applications attacking each other. That includes your web browser, the JS in it, or any other ad-laden crapware attack your local applications, e.g. to steal credit cards, SSH keys, etc. Side-channels are pernicious. In the limit, they give applications unfettered read access across protection boundaries. If we don't shut them down, we might as we…

> Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space?

> Of course not.

So if it's not OK for processes to read each others' address spaces, does that mean it's not OK to attach gdb to a running process to figure out where it's stuck at, without running gdb as root? I chose to reenable ptrace among sibling processes on my system out of convenience, and hopefully it's not too much of a vulnerability. (I also chose to enable passwordless sudo, which is convenient, but probably dangerous as well. I wonder if I can use my hardware security key for sudo instead.)

Re: Spectre mitigations murder userspace performance

#240

Post by tcoff91 »

kurikuri wrote: post #231
dijit wrote: post #14

Earlier quoted context omitted.

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

>desktop executes untrusted and rather arbitrary code pretty often Aren’t the most affected group of users cloud users (and providers), not desktop users? I thought the biggest risk of specter attacks is the ability to glean information on other server residents who should be segmented off. There are many more concerns in user space which make attacking a desktop with specter pretty cumbersome for low reward wrt oppo…

I was under the impression that spectre is is much more limited in scope than Meltdown. I think you have to be in a position to influence the execution of the program you are trying to extract information from. Like JavaScript engines running in browsers. One example is your JS can be used to get the browser to speculatively execute something that leaks data. I think that it’d be pretty hard for one VM to set up a spectre attack on another arbitrary VM. Meltdown however does expose everything.
Post reply on HN