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

171–180 of 294 posts

Re: Spectre mitigations murder userspace performance

#171

Post by slver »

kyledrake wrote: post #164

Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways. I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just becau…

JS is already treated like code you can’t trust. Adjustments will be needed from time to time.

A full block would not be for engineering reasons, but for ideological reasons.

Re: Spectre mitigations murder userspace performance

#173

Post by rkagerer »

rkagerer wrote: post #158
tyingq wrote: post #20

Earlier quoted context omitted.

Nice 3rd party toggle for windows: https://www.grc.com/inspectre.htm Or a Powershell script from MS: https://support.microsoft.com/en-us/topic/understanding-get-...

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 corresponding mitigation is enabled, if 1 it's disabled. FeatureSettingsOverrideMask is simply a mask to control which bits of FeatureSettingsOverride to apply. So, for example, FeatureSettingsOverride = 2 and FeatureSettingsOverrideMask = 3 would enable the Spectre mitigation (if available) and disable the Meltdown one.

More info here:

https://support.microsoft.com/en-us/topic/windows-server-gui...

https://gist.github.com/daBONDi/6f86210e54c68e84e85372fc4d1f...

Haven't checked if the program emits different behavior for other CPU's or OS versions.

Re: Spectre mitigations murder userspace performance

#174

Post by emilfihlman »

Filligree wrote: post #47
emilfihlman wrote: post #42

Can we have syscall chaining finally? Please? There is literally no reason why we couldn't have it.

Do you mean io_uring?

No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done.

Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace.

An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if you need to do it multiple times quickly, and actually doing it even once is really expensive if your sets are large.

Re: Spectre mitigations murder userspace performance

#175

Post by LinuxBender »

kevingadd wrote: post #159
callahad wrote: post #145

Earlier quoted context omitted.

Give it time; it's a trickle campaign. Just this morning I updated my Win 10 Pro desktop, and on reboot I got a full screen wizard prompting me to "use recommended browser settings" which is doublespeak for changing my default browser to Edge. Edit: On re-reading, I believe OP was specifically referring to false positives with SmartScreen that crop up regularly, like at https://www.reddit.com/r/firefox/comments/n7gig…

The SmartScreen stuff is a plague that applies to all software developers in varying degrees. Chrome does this with their safe browsing stuff too, I hate it - essentially everyone gets told your exe is "malicious" until enough people have downloaded it without it being flagged as malware. The idea that it applies to trusted vendors like Mozilla shipping code-signed executables is bonkers to me. Nice way to promote fu…

You can disable SmartScreen with O&O ShutUp10 [1] on the home version.

[1] - https://www.oo-software.com/en/shutup10

Re: Spectre mitigations murder userspace performance

#176

Post by emilfihlman »

hinkley wrote: post #134
Filligree wrote: post #47

Earlier quoted context omitted.

Do you mean io_uring?

Doesn’t that address fanout, not chaining? Chaining RPC calls requires something more sophisticated.

Io_uring doesn't even address fanout if you mean writing the same data to multiple fds.

Io_uring is just a way to have "do this and tell me when it's done" io.

Re: Spectre mitigations murder userspace performance

#177

Post by usrusr »

pjmlp wrote: post #70
hjek wrote: post #44

Earlier quoted context omitted.

> Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. Per-process Spectre mitigations could be helpful there, but I don't understand the technical details to know whether that would be possible to implement. It would be nice to disable mitigations on a video editor and for gaming.

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.

Re: Spectre mitigations murder userspace performance

#178

Post by kyledrake »

staticassertion wrote: post #169
kyledrake wrote: post #164

Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways. I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just becau…

You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. I think one problem with the comments about this post is that they doesn't emphasize enough that the hit is to system call heavy workloads. This is NOT a global slowdown of all compute. The hit is to system call performance, and it's big, no question, but I don't think we need to throw out the internet's…

> You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea.

It's absolutely reasonable to require the user to give a web page permission to start executing powerful, potentially dangerous code on their computer. Also JavaScript is not "the internet", nor is it even really "the web", which for most of its history was relatively benign HTML documents that you read, and things have frankly been on a downward trajectory in terms of safety and usability since we started changing it.

Powerful JS is a relatively recent phenomenon in the history of the web, and largely under the theory that we can do it safely with correct design. As someone that has to moderate code on un-trustable web sites as part of my work, I can just say it's not working out very well, even leaving out stuff like spectre/meltdown.

Re: Spectre mitigations murder userspace performance

#179

Post by staticassertion »

kyledrake wrote: post #178
staticassertion wrote: post #169

Earlier quoted context omitted.

You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. I think one problem with the comments about this post is that they doesn't emphasize enough that the hit is to system call heavy workloads. This is NOT a global slowdown of all compute. The hit is to system call performance, and it's big, no question, but I don't think we need to throw out the internet's…

> You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea. It's absolutely reasonable to require the user to give a web page permission to start executing powerful, potentially dangerous code on their computer. Also JavaScript is not "the internet", nor is it even really "the web", which for most of its history was relatively benign HTML documents that you rea…

I don't think this would solve anything. This is like putting Word macros behind a "do you want to run this macro?". Yes, yes they do want to run it.

If people were willing to put every webpage behind a "do you want to run this webpage" we'd see them all using noscript already - virtually no one wants that experience.

> largely under the theory that we can do it safely with correct design

I blame operating systems and hardware vendors tbh. It's their job to make this safe, and they do a pretty bad job of it. Browser vendors have had to pick up a massive amount of slack to try to compensate, to the extent that browser teams have to make major patches to the Linux kernel.

Re: Spectre mitigations murder userspace performance

#180

Post by kyledrake »

slver wrote: post #171
kyledrake wrote: post #164

Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways. I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just becau…

JS is already treated like code you can’t trust. Adjustments will be needed from time to time. A full block would not be for engineering reasons, but for ideological reasons.

"Strong JavaScript" continues to fail this trust model even with very careful design, leading to (among other things) mitigations in the form of multiple double digit performance hits to all computing. That seems more like an engineering reason to re-evaluate the status quo to me. "Web sites should be allowed to run untrustable executable code because we can manage it" feels far more ideological to me, because it's based on a belief that is becoming increasingly unfounded by the accumulating evidence.
Post reply on HN