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

91–100 of 294 posts

Re: Spectre mitigations murder userspace performance

#91

Post by teddyh »

cj wrote: post #64
jacquesm wrote: post #61

Earlier quoted context omitted.

This is fair, but at least you're sure that when you close the window that it's gone and that is as far as I'm concerned its biggest feature. Oh, and that it seems to work well on all platforms.

“Close browser tab” - immediately exits a Google Meet. Closing a Zoom/Webex meeting, who knows since it’s still running in the background. I also like meetings sandboxed in a browser so weird things like “automatically take control of your screen and maximize window” doesn’t happen when someone in a Zoom meeting starts sharing their screen. Even at the expense of more CPU.

> “Close browser tab” - immediately exits a Google Meet.

How would you know? Or, put another way: Why don’t you want to trust Google Meet, but apparently want to trust Google Chrome?

Re: Spectre mitigations murder userspace performance

#92

Post by formerly_proven »

jacquesm wrote: post #58
dustingetz wrote: post #29

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…

> You never sent me a response on the question of what things an app would do that would make it run with MS-DOS and not run with DR-DOS. Is there [a] feature they have that might get in our way?

Bill Gates

> What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS.

MS SVP Brad silverberg

> If you're going to kill someone there isn't much reason to get all worked up about it and angry. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger.

MS VP Jim alchin

What has changed? Nothing, of course. Settling and paying fines for blatant abuses of dominant market positions has been Microsoft’s MO for decades.

Re: Spectre mitigations murder userspace performance

#94

Post by jfrunyon »

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…

> 4KB/s (basically dialup speed)

I guess if "basically" means "takes 10x longer"?

Re: Spectre mitigations murder userspace performance

#95

Post by diegocg »

netr0ute wrote: post #21
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.

That's what JavaScript blockers like NoScript and uBlock Origin are for.

Ad blockers can not know if a JavaScript algorithm is dangerous or not

Re: Spectre mitigations murder userspace performance

#96

Post by PedroBatista »

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

Re: Spectre mitigations murder userspace performance

#97

Post by DSingularity »

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…

If users are still unable to recognize when they are doing something security sensitive then how can we remove all safeguards?

Re: Spectre mitigations murder userspace performance

#98

Post by gruez »

SkyMarshal wrote: post #87
voakbasda wrote: post #74

Earlier quoted context omitted.

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

Re: Spectre mitigations murder userspace performance

#99

Post by ulzeraj »

cj wrote: post #64
jacquesm wrote: post #61

Earlier quoted context omitted.

This is fair, but at least you're sure that when you close the window that it's gone and that is as far as I'm concerned its biggest feature. Oh, and that it seems to work well on all platforms.

“Close browser tab” - immediately exits a Google Meet. Closing a Zoom/Webex meeting, who knows since it’s still running in the background. I also like meetings sandboxed in a browser so weird things like “automatically take control of your screen and maximize window” doesn’t happen when someone in a Zoom meeting starts sharing their screen. Even at the expense of more CPU.

That meme with the actor taking to a bloodied Jesus comes to mind while reading you guys comparing google with zoom. You guys are so lucky. I work on Skype for Business over a Citrix Workspace connection.

While Skype is an unmitigated disaster that can’t do simple stuff like copying text there is Citrix that requires a wizard installer with admin rights that deploys 3 background services and requires an audio plugin (separated, with another wizard installer) to do a worse remote streaming experience than what discord does for teenagers using a browser.

Re: Spectre mitigations murder userspace performance

#100

Post by homerowilson »

temac wrote: post #35
infogulch wrote: post #15

Earlier quoted context omitted.

I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths. I like the way the mill approaches these architectural problems.

This has been tried (not on vaporhardware Mill, I'm more thinking about e.g. Intel Itanium) and it failed. The reason is extremely simple: a speculative OOO processor optimizes dynamically. If you switch that with static compile time optimizations, you are bound to only be as fast as before in some quite limited parameter ranges (like: number of entries in a hash table, size of an image, etc.)

Also don't forget the really interesting Transmeta processors, also ultimately a failure. VLIW is very difficult in practice.
Post reply on HN