Live data from Hacker News

Spectre mitigations murder userspace performance

robert.ocallahan.org

81–90 of 294 posts

Re: Spectre mitigations murder userspace performance

#81

Earlier quoted context omitted.

your desktop is already rooted by Zoom

And teams. And all that software that you used to be able to use that you have to make exceptions for so that in the end you end up forgetting to re-enable some critical part of the windows scareware implementation. Seriously: try installing Firefox on Windows 10 (I had to do this recently, I have now one computer in the house on Win 10 due to a hard requirement for some software/hardware combo), and you'll see Micro…

>Oh, and Google will return a link for Chrome as the first item when you search for Adblock for Firefox. You can't make this stuff up.

Maybe your profile affects results, here:

"Adblock for Firefox"

returns

"https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/"

"adblock"

returns 1st url = https://adblockplus.org

2nd url is = chrome.google.com

Re: Spectre mitigations murder userspace performance

#82

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…

yes, I am interested in this.. basically I have mitigations OFF and also, do not run a web browser on the base OS. (Debian/Ubuntu here) in VMs I do run the browser, with two or three in use daily..

Re: Spectre mitigations murder userspace performance

#84

Earlier quoted context omitted.

Yes, but your fans would start spinning like mad. I kill any browser that does that. You’d have to execute a successful attack within a few seconds to pull it off. I think that’s a risk I’ll take.

> Yes, but your fans would start spinning like mad. I kill any browser that does that. Good lord, I hope this is satire.

I think they mean the browser window/process. I also tend to kill off tabs that do this.

Re: Spectre mitigations murder userspace performance

#85
post #78

I would love to see new chips that take all of the transistors used for speculation and use them for more cores. I asked electrical engineers once how many of the transistors on a chip serve speculation, and they said, "To a first approximation, 100%." That means we could add a lot more cores. Add enough, and the OS could easily pin basically all processes/threads to their own cores. And that, I believe, might win so…

> take all of the transistors used for speculation and use them for more cores

We have these - they're called GPUs!

https://www.nvidia.co.uk/content/PDF/fermi_white_papers/P.Gl... provides a good overview (search the word "speculative"):

> Since most of the circuitry within each core is dedicated to computation, rather than speculative features meant to enhance single-threaded performance, most of the die area and power consumed by Fermi goes into the application’s actual algorithmic work.

But GPUs are far from easy to code for, even in 2021, and there are a lot of workloads that benefit from speculative branching. Having a combination of GPU cores and speculative CPU cores in an architecture allows you to access the best of both worlds.

Re: Spectre mitigations murder userspace performance

#86
post #49
post #30

Earlier quoted context omitted.

I don’t think that’s a good safety heuristic.

I agree that it's not good, yet anecdotally I've realized that a device has been compromised by running `top`, on Windows and on Linux. It's not a good heurestic because it's only disvoverable post-compromise.

I’ve discovered a compromise before because of the fans going full speed on a server.

Re: Spectre mitigations murder userspace performance

#87
post #71

Earlier quoted context omitted.

I don't want to go into this topic because frontend developers are very defensive of their capability to Javascript on people, they often cite javascript adoption numbers as proof that it's fine to make it mandatory or cite complex web applications as a reason for it to be mandatory for all sites, which I personally find to be a false dichotomy. I tend to agree with what you're saying but the ship has sailed very muc…

Entirely? Use NoScript to temporarily enable only those portions of the single site that you need. No affiliation, just a happy user.

/second NoScript. Instead of whitelisting whole sites, you can whitelist links to JavaScript imports across all sites, temporarily or permanently.

So for example, you can whitelist urls to all the major JavaScript frontend frameworks’ CDNs, like bootstrap, etc. while leaving known trackers and spyware blacklisted by default.

Anecdotally it seems most websites still work with their trackers disabled, as long as they have their frontend framework/s loaded.

Re: Spectre mitigations murder userspace performance

#89

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

has there been any research on what hardware changes would be necessary to reclaim performance? I've noticed extreme stutter events on desktop OSX for the last 2 years. Would be curious if its related.

Re: Spectre mitigations murder userspace performance

#90

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…

Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link". https://www.zdnet.com/article/google-this-spectre-proof-of-c... Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.

Yeah no disagreement there. I had totally forgotten about the JS POC - ugh!

The JavaScript argument is interesting to me in that it's already flawed. I suppose I'd rather focus on the security issues with browsers running code on my computer more than anything else since it's effectively the "but what about ___" answer to so many threads like this one.

I've seen a few other comments suggesting per-process rules to enable or disable branch protections. That's an interesting thought, especially considering you could apply it to either "trusted" or "untrusted" code depending on it's source.

Post reply on HN