Spectre mitigations murder userspace performance • Hacker News Board

Re: Spectre mitigations murder userspace performance

#241

Post by BuyMyBitcoins » Sun, Jun 20, 2021, 1:17 AM UTC

christophilus wrote: post #25

thanksforfish wrote: post #9

Earlier quoted context omitted.

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.

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.

I can’t tell you how many startup’s splash page animations have actually caused my PC fans to spin at maximum. What is this website possibly doing with all my available computing power?

Re: Spectre mitigations murder userspace performance

#242

Post by winrid » Sun, Jun 20, 2021, 1:24 AM UTC

I wonder if this is part of why the M1 chip pulls ahead?

Re: Spectre mitigations murder userspace performance

#243

Post by cartoonworld » Sun, Jun 20, 2021, 2:22 AM UTC

argomo wrote: post #160

gruez wrote: post #98

Earlier quoted context omitted.

I disagree. There are way too many sites that require javascript that you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.

I used to do this. It broke too often when doing credit card purchases though... it would take multiple attempts to complete a purchase and figure out which domains needed to be enabled. Sometimes the status would be left ambiguous. Once I double-spent, but fortunately it was a cancellable reservation. I suppose you can do better if you just spend at a few key sites.

I have used NoScript for over a decade and I've been bitten by this too, but I've noticed that it has gotten better. CC processors seem to have encountered enough crappy browsers and broken JS implimentations that they've improved their services in the last half dozen years or so.

That said, when there's something old, important, and/or dumb looking, I usually spawn a new Firefox container (using Multi-Account Container plugin) and use NoScript's temporary bypass function.

Re: Spectre mitigations murder userspace performance

#244

Post by chithanh » Sun, Jun 20, 2021, 2:24 AM UTC

foobarbazetc wrote: post #238

kurikuri wrote: post #231

Earlier quoted context omitted.

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

To be more precise, running different cloud customers on different SMT threads of the same core allows them to attack each other.

This is also the case with Spectre-related vulnerabilities such as L1TF.

Re: Spectre mitigations murder userspace performance

#245

Post by genmud » Sun, Jun 20, 2021, 2:42 AM UTC

usrusr wrote: post #177

pjmlp wrote: post #70

Earlier quoted context omitted.

If gaming implies a MMO, a possible attack vector is attacking users to get hold of their gaming account details and do as they please.

The way I understand it (not that well, admittedly), per-process mitigations would be all about keeping that process from reading other memory areas, not about protecting that process from others. Which is better than the reverse if your intention is to allow some processes to run random js.

The problem with spectre/meltdown is they don't use standard calls to ask for memory of other processes... that is the vulnerability.

If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected and is much more impactful than people think... for example, because the bug allows reading from nearly any memory address space, you could also pull in things like crypto keys from the OS or passwords from memory.

Re: Spectre mitigations murder userspace performance

#246

Post by smichel17 » Sun, Jun 20, 2021, 3:22 AM UTC

argomo wrote: post #160

gruez wrote: post #98

Earlier quoted context omitted.

I disagree. There are way too many sites that require javascript that you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.

I used to do this. It broke too often when doing credit card purchases though... it would take multiple attempts to complete a purchase and figure out which domains needed to be enabled. Sometimes the status would be left ambiguous. Once I double-spent, but fortunately it was a cancellable reservation. I suppose you can do better if you just spend at a few key sites.

I do it with uMatrix. I usually go up to the "all sites" level and enable most everything before going through a credit card payment flow, for this reason.

Security is only part of my motivation, though, and not the main part -- I mostly do it because it protects me by default from all the pop-up type crap that so many websites foist on you. Yes, it's a pain to un-break sites sometimes. But I resent it less than going through the equivalent pain in "privacy settings" popups, wriggling chat widgets, "ate you sure you don't want to sign up for our newsletter?" nags, etc. Websites are already broken; as long as that's true, I'd rather be in control of why.

Re: Spectre mitigations murder userspace performance

#247

Post by blarg1 » Sun, Jun 20, 2021, 3:33 AM UTC

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 wonder if I would be safe to use this if I removed all my sensitive passwords from the browser's password manager and/or harddrive?

Does anyone know what is at risk from these exploits?

Re: Spectre mitigations murder userspace performance

#248

Post by tabokie » Sun, Jun 20, 2021, 3:41 AM UTC

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…

At least on AWS EC2, malicious neighbors won't be an issue. "This issue has been addressed for AWS hypervisors, and no instance can read the memory of another instance, nor can any instance read AWS hypervisor memory. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads."[1]

[1] https://aws.amazon.com/speculative-execution-os-updates/

Re: Spectre mitigations murder userspace performance

#249

Post by lanstin » Sun, Jun 20, 2021, 5:01 AM UTC

gruez wrote: post #197

beebeepka wrote: post #149

Earlier quoted context omitted.

I've been using noscript for at least a decade and it hasn't happened yet. I have conditioned my wife to use it too. She doesn't do it either

So what happens if you go to a site and see a blank/broken page? Do you just go back and abandon the page? Do you do a full risk assessment of each of the domains? What does that assessment entail?

First I curse JavaScript developers (sorry). Then I use a heuristic like is this a real website for a real thing that I heard of before today, then temp trust; if it’s click baity or new, don’t trust or try adding in one at a time or mostly just give up. Very little shortage of content.

Re: Spectre mitigations murder userspace performance

#250

Post by lanstin » Sun, Jun 20, 2021, 5:03 AM UTC

KronisLV wrote: post #136

alisonkisk wrote: post #119

Earlier quoted context omitted.

I like this breakage because it makes me unhappy with the website and less likely to use it -- the immune system is working as it should.

That's probably a good approach for random news sites and such, much less so when your internet banking and even online shopping sites require JS on.

If the actual payment is via Paypal I think it usually works without JavaScript in the merchant. And like content, there is no shortage of places to buy stuff.

For banking i use their phone app or else visit them in person. But I use a credit union not a bank as I want to trust the people holding my money.