Spectre mitigations murder userspace performance • Hacker News Board

Re: Spectre mitigations murder userspace performance

#261

Post by saati » Sun, Jun 20, 2021, 9:12 AM UTC

staticassertion wrote: post #223

dijit wrote: post #220

Earlier quoted context omitted.

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

Yeah that should be really fast, still. Programs could also opt to just tell the OS "hey don't check this system call from me", on each system call, avoiding any lookup. The impact of TLB flushing, not just the cost of the flush, is really significant - it's going to take a lot of work to be as expensive within the syscall path.

What would stop malware telling the os to not check it?

Re: Spectre mitigations murder userspace performance

#262

Post by josteink » Sun, Jun 20, 2021, 9:16 AM UTC

saagarjha wrote: post #156

astrange wrote: post #10

Earlier quoted context omitted.

> I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Have you seen how happy people are with M1 machines? That's because it's faster. It's definitely not simpler. > Most of the real slowdowns anyone has in day to day performance has more to do with inefficient code than hardware anyway…

Wait until Slack outfits their developers with M1 machines and we’ll quickly be back to being unhappy again.

I know this sounds radical, but uh, if everyone hates slack how about not using slack?

Re: Spectre mitigations murder userspace performance

#263

Post by richrichardsson » Sun, Jun 20, 2021, 9:18 AM UTC

jacquesm wrote: post #63

eloff wrote: post #53

Earlier quoted context omitted.

They tried. The V8 team eventually gave up and said it was unwinnable. What they did do is move tabs to their own process so they can take average of the operating systems protections. Yes you can read the memory of the process hosting the JavaScript, but now there isn't anything interesting in it. Google's security team released a proof of concept attack that can read the memory in the renderer in many systems.

average -> advantage

Didn't even notice until reading this comment! I think my brain said, "starts with an A, got a V near the beginning, ends in AGE, must be ADVANTAGE in this context."

Re: Spectre mitigations murder userspace performance

#264

Post by astrange » Sun, Jun 20, 2021, 9:26 AM UTC

ghoward wrote: post #256

saagarjha wrote: post #168

Earlier quoted context omitted.

Hey, I just read your blog post, and while I assume you have an interest in making improvements in this area I think you’re handwaving away a lot of concerns, and are seemingly unaware of many other issues in ways that significantly affect the viability of your designs. If I could come up with an analogy, it might be like if I wrote the following about cars: “Car design has stagnated for decades. They emit massive am…

You have good points, but I think you misunderstand the post in many ways. First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side. Second, I am not referring to dynamic linking. Dynamic linking requires jump tables becau…

> First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side.

CompCert has not actually been formally verified - only the middle-end has. The C preprocessor and assembler aren't, the frontend formerly wasn't (but I think is now), and bugs have been found in those parts by fuzzing.

Plus being a faithful implementation of the C spec certainly leaves room for security issues…

(Why do we say "formally verified"? It sounds like weasel words. What is formal about it?)

Re: Spectre mitigations murder userspace performance

#265

Post by usrusr » Sun, Jun 20, 2021, 9:29 AM UTC

genmud wrote: post #245

usrusr wrote: post #177

Earlier quoted context omitted.

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

Yeah, but if you can mitigate per process, you can keep the secrets of trusted code from the eyes of untrusted code by only affecting the performance of the untrusted processes. The way I understand it the "protection cost" would fall on potential attackers, not on potential victims (unless of course they are both, holders of secrets and runners of untrusted code).

Re: Spectre mitigations murder userspace performance

#266

Post by Popegaf » Sun, Jun 20, 2021, 9:40 AM UTC

So if I understand this right, CPUs try to predict what operations are going to be made in order to gain performance, but instead introduced a vuln that killed performance? Wouldn't the logical thing be then to get rid of the predictions on hardware in order to be able to turn off these mitigations?

Are there CPUs out there / being made without these SoC predictions?

Re: Spectre mitigations murder userspace performance

#267

Post by saagarjha » Sun, Jun 20, 2021, 9:52 AM UTC

josteink wrote: post #262

saagarjha wrote: post #156

Earlier quoted context omitted.

Wait until Slack outfits their developers with M1 machines and we’ll quickly be back to being unhappy again.

I know this sounds radical, but uh, if everyone hates slack how about not using slack?

This is often the same as saying "how about you quit your job".

Re: Spectre mitigations murder userspace performance

#268

Post by beebeepka » Sun, Jun 20, 2021, 9:56 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?

Depends. Sometimes I leave immediately, other times that blank is just a cover on top of content. And finally, I sometimes have to enable a domain/subdomain using common sense.

It's not that hard, nor time consuming. Again, my wife can do it and she's not a developer.

Still though. There are sites that would not work at all until everything is enabled, including ads. Imagine not being able to buy a plane ticket because wizzair wants to serve you ads

Re: Spectre mitigations murder userspace performance

#269

Post by josteink » Sun, Jun 20, 2021, 10:15 AM UTC

saagarjha wrote: post #267

josteink wrote: post #262

Earlier quoted context omitted.

I know this sounds radical, but uh, if everyone hates slack how about not using slack?

This is often the same as saying "how about you quit your job".

But why does companies use slack if “everyone” hates it? For once, I’ve never been to a company which uses it.

There are literally countless options in the IM/groupware field which is not Slack.

Re: Spectre mitigations murder userspace performance

#270

Post by dkarras » Sun, Jun 20, 2021, 11:08 AM UTC

Popegaf wrote: post #266

So if I understand this right, CPUs try to predict what operations are going to be made in order to gain performance, but instead introduced a vuln that killed performance? Wouldn't the logical thing be then to get rid of the predictions on hardware in order to be able to turn off these mitigations? Are there CPUs out there / being made without these SoC predictions?

I'm not sure if I got you right: The performance boost with speculative execution is massive. It introduces a vuln. It is the fix for that vuln that kills the performance.