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

191–200 of 294 posts

Re: Spectre mitigations murder userspace performance

#191

Post by pstuart »

rbanffy wrote: post #183
jacquesm wrote: post #58

Earlier quoted context omitted.

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…

> Has there ever been a large company in IT that didn't turn absolutely evil as soon as the opportunity presented itself? If turning evil increases shareholder value, it’s their fiduciary duty to do so.

> If turning evil increases shareholder value, it’s their fiduciary duty to do so.

Meh. Maybe not: https://medium.com/bull-market/there-is-no-effective-fiducia...

Re: Spectre mitigations murder userspace performance

#192

Post by SkyMarshal »

msbarnett wrote: post #182
SkyMarshal wrote: post #155

Earlier quoted context omitted.

I disagree. I'm not just pulling this out of my ass, I've been doing exactly this for years, I can't remember how long. It works fine. >you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits. The key here is that when you're deciding whether to whitelist a JS import, and you don't know what it is and don't want to take the time to look it up, then whitelist…

> Only permanently whitelist JS that you know for sure isn't a tracker or malware or sketchy. What’s the whitelist based on? URI? Or file content hash? Because today’s “criticalsitefunctunality.js” is tomorrow’s “upstream got p0wned and there’s a Bitcoin miner in there too now”. Sites churn so often that “permanently” whitelisting hashes is probably a never ending chore, and you’re unlikely to want to constantly re-i…

I'm aware of all that, but it's not theater, it's just part of a defense in depth strategy. Reduces attack surface area, doesn't eliminate it, while maintaining usability of the web.

If you have a better approach that accomplishes both of those objectives, do tell.

Re: Spectre mitigations murder userspace performance

#193

Post by squiggleblaz »

Nullabillity wrote: post #66
kzrdude wrote: post #54

Earlier quoted context omitted.

Vscode is a browser

As in "it runs JavaScript and renders HTML", yes. As in "it runs stuff in a security sandbox", no.

How about extensions? I would have thought these amount to a comparable security concern as web pages. Do they have adequate isolation?

Re: Spectre mitigations murder userspace performance

#194

Post by msbarnett »

pjmlp wrote: post #188
titzer wrote: post #57

Earlier quoted context omitted.

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…

That would be only on the context of shmem, right? I would assume other IPC mechanisms are safe from it.

You would assume incorrectly.

Re: Spectre mitigations murder userspace performance

#195

Post by SkyMarshal »

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.

>it would take multiple attempts to complete a purchase and figure out which domains needed to be enabled.

Yeah I went through this too, figuring out all the CC purchase redirects. Some are just idiotic to the point I wish govts would pass a law mandating zero redirects for online purchases. Stripe, Paypal, Square, Braintree and a few others do payments just fine without the redirects so it's clearly possible.

But eventually even that gets solved and the redirects get whitelisted. Haven't encountered this problem for a long time.

Re: Spectre mitigations murder userspace performance

#196

Post by gruez »

hutzlibu wrote: post #127
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.

You probably misunderstood : allmost all websites require javascript, yes - but you can selectivly allow only the javascript of that site, their framework etc. and block all the tracker/ads javascript with NoScript/UBlock - and then it is working and probably quite safe. But to mitigate, more and more websites find ways to sneak in the tracker/ads/analytics into the main sites js. So it is not as easy, either. Which…

>but you can selectivly allow only the javascript of that site, their framework etc. and block all the tracker/ads javascript with NoScript/UBlock

What's the difference between that and just using the standard easylist/easyprivacy filter? I suppose there's a small chance that a third party site went rogue and isn't on the default lists, but I'm skeptical how many attacks that would thrawt in reality. The attacks I heard of tend to be first party/supply chain (would be white listed by you), or delivered through an ad network (probably already be on a blacklist).

Re: Spectre mitigations murder userspace performance

#197

Post by gruez »

beebeepka wrote: post #149
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'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?

Re: Spectre mitigations murder userspace performance

#198

Post by Datagenerator »

rkagerer wrote: post #173
rkagerer wrote: post #158

Earlier quoted context omitted.

I'd like some more technical details on what exactly InSpectre does (specifically for the Meltdown patch). e.g. Does it just flip a registry key? Rewrite a microcode patch somewhere? Couldn't find an explanation in the software (even under Show Tech Details) or on their site; could you point me to it? Also, do all the major browsers now have their own mitigations built in?

Answering my own Question #1: Looks like it sets values for FeatureSettingsOverride and FeatureSettingsOverrideMask under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" registry key. FeatureSettingsOverride is a bit field where bit 0 controls the mitigation for CVE-2017-5715 (Spectre) and bit 1 controls it for CVE-2017-5754 (Meltdown). If the bit value is 0 the correspondi…

Propitiatory big brother OS has some cryptic setting, so? Linux and BSD give the user all sorts of freedom Microsoft never will. Freedom to research the source, ability to disable telemetry if that would exist and so on.

Re: Spectre mitigations murder userspace performance

#199

Post by josefx »

gruez wrote: post #98
SkyMarshal wrote: post #87

Earlier quoted context omitted.

/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 h…

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 feel that is a bit like driving blindfolded because you might get distracted at some point anyway. Sure that one script you have to enable might be the one to exploit your system, but it might also be one of the dozens that didn't do anything useful.

Re: Spectre mitigations murder userspace performance

#200

Post by gruez »

SkyMarshal wrote: post #192
msbarnett wrote: post #182

Earlier quoted context omitted.

> Only permanently whitelist JS that you know for sure isn't a tracker or malware or sketchy. What’s the whitelist based on? URI? Or file content hash? Because today’s “criticalsitefunctunality.js” is tomorrow’s “upstream got p0wned and there’s a Bitcoin miner in there too now”. Sites churn so often that “permanently” whitelisting hashes is probably a never ending chore, and you’re unlikely to want to constantly re-i…

I'm aware of all that, but it's not theater, it's just part of a defense in depth strategy. Reduces attack surface area, doesn't eliminate it, while maintaining usability of the web. If you have a better approach that accomplishes both of those objectives, do tell.

I'm sure it adds some amount of security. I'm just skeptical it adds enough security to be worth the hassle. I discussed the threat model here: https://news.ycombinator.com/item?id=27564457 and came to the conclusion that it wouldn't prevent much attacks in practice.
Post reply on HN