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

211–220 of 294 posts

Re: Spectre mitigations murder userspace performance

#211

Post by userbinator »

titzer wrote: post #60
christophilus wrote: post #25

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.

If this is your security mechanism (chuckle), then attackers will just slow themselves down by duty cycling. Say, only attacking for 100ms at a time, then sleeping a second. You'd never know.

...making it even more unlikely the attack would find anything of value (or even recognisable as such) in a reasonable amount of time.

To use an analogy, these side-channel timing attacks are really a "looking for a needle in a haystack" (or heap...) situation, except that [1] you don't necessarily know what a needle looks like, and [2] the haystack is constantly changing. AFAIK all the PoCs shown so far relied on having a deep knowledge of the system and carefully constructed conditions.

If these attacks could undetectably dump all of your RAM in a few seconds, that would definitely be a huge concern. But they're more like being able to read a few bytes per second, from somewhere in the address space, with no idea what they are or where they're being read from, and no guarantee that they're even contiguous.

Re: Spectre mitigations murder userspace performance

#213

Post by userbinator »

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…

address the issue of local applications attacking each other.

IMHO it's stupid to even try to isolate processes to that extent, as it's a really deep rabbithole that'll lead to worse performance and dubious increases in actual security. The best defense is to simply make everything running on the system be trusted.

Process protection boundaries should be for protection against accidental cross-process corruption, a form of reliability, and nothing more. That's effectively what the early 286/386 documentation stated, so Intel never even intended these protections to be defenses against side-channels in the first place.

Of course, the "security industry" needs to keep creating paranoia-fuel to justify their existence...

Re: Spectre mitigations murder userspace performance

#214

Post by IshKebab »

squiggleblaz wrote: post #193
Nullabillity wrote: post #66

Earlier quoted context omitted.

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?

No, extensions are fully trusted. They can do anything.

Re: Spectre mitigations murder userspace performance

#215

Post by wizzwizz4 »

saagarjha wrote: post #154
wizzwizz4 wrote: post #143

Earlier quoted context omitted.

> And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. How will we ever know that a Sufficiently Smart Compiler is impossible, if we never have processors where compiler intelligence is useful?

> And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").

And how can one get their hands on an Itanium machine? It's a dead architecture in less than two weeks, and for the last decade the things have been almost exclusively enterprise machines; not something the hobbyist (or even the academic!) is likely to get access to.

Do you have an HP zx6000 lying around, perchance?

Itanium failed early; it had many more problems than compilers. And if we don't have a replacement, we'll never get those compilers from anyone but the most obsessed.

Re: Spectre mitigations murder userspace performance

#216

Post by hutzlibu »

_meqs wrote: post #157
hutzlibu wrote: post #131

Earlier quoted context omitted.

" Has there ever been a large company in IT that didn't turn absolutely evil as soon as the opportunity presented itself?" I like nuances, though. "absolute evil" is a bit strong. There were companies who were engaged with enslaving people and working them to death. (some still are) I am no fan of googles development, but absolute evil leaves no room to describe other companies who are actually worse.

> some still are well that's an understatement[0]. I alos think it's less productive to interpret the phrase absolute evil as a comment on an entity's moral alignments (because it's a corporation, it's not chaotic evil or neutral good, it just is) but as a comment on the foundation and effects of the economic and political systems defining of the corporations (capitalism under neoliberalism). Absolute evil seems like…

There is still a big difference, between exploiting people - and owning people - and literal doing what you want with them. Flock them. Burn them. Rape them - as you please. This is slavery as it used to be (and partly still is!!). And that term gets watered down when applied to something else.

Exploiting people because they are desperate is a big problem. Maybe call it modern day slavery. But it really is not the same as what slavery means for people who are literaly and 100% owned by others.

Re: Spectre mitigations murder userspace performance

#217

Post by staticassertion »

dijit wrote: post #186
staticassertion wrote: post #165

Earlier quoted context omitted.

I don't think that (3) is true.

How would you implement such a change? Considering that you have: A) some list of allowed applications/programs B) a run of this check on every syscall C) to be faster than a TLB flush

I don't know but I can't imagine a highly predictable branch being slower than a TLB flush.

Re: Spectre mitigations murder userspace performance

#218

Post by hutzlibu »

SkyMarshal wrote: post #208
gruez wrote: post #196

Earlier quoted context omitted.

>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 he…

Easylist and Privacylist are great. I suppose the main reasons for doing it manually are seeing firsthand what all the sites you visit are doing behind the scenes, and getting a sense of what is legitimately needed functionality, what isn't, and what is just downright sketchy.

Yup. But you can only do this when you have time for it. I kind of got very pragmatic with it.

Re: Spectre mitigations murder userspace performance

#219

Post by thrower123 »

matsemann wrote: post #55
bostonsre wrote: post #51

Earlier quoted context omitted.

Seriously. I hate zoom, there are so many features that smell like malware (how when a call starts sometimes my system level volume no longer is controllable and I have to go to zoom settings to control it. I have windows+wsl, but it's happened on macs in my company as well). Google gets a lot of hate, but I like their meeting tool because they keep it simple and it works.

I just changed company. Wish I could go back to Zoom. Google Meet is horrible. I have to open Chrome for all meetings, as it (probably intentionally) runs worse in other browsers. But even in Chrome there are issues. Some workloads (like running tests) can take 5x as long on my system if I'm sharing my screen on Meet. Making working with others more hassle than it should be.

There has never been a webmeeting software that people didn't bitch about constantly. They all suck, because, fundamentally, what they are trying to accomplish sucks. Nobody wants to do audio/video meetings, we just suffer through them because we have to.

Re: Spectre mitigations murder userspace performance

#220

Post by dijit »

staticassertion wrote: post #217
dijit wrote: post #186

Earlier quoted context omitted.

How would you implement such a change? Considering that you have: A) some list of allowed applications/programs B) a run of this check on every syscall C) to be faster than a TLB flush

I don't know but I can't imagine a highly predictable branch being slower than a TLB flush.

Well consider the fact that checking a table of “ok” programs is a branch and a lookup in of itself.
Post reply on HN