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

201–210 of 294 posts

Re: Spectre mitigations murder userspace performance

#201

Post by giantrobot »

nickpeterson wrote: post #3

I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. 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”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…

> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out.

You're oversimplifying the situation and drawing conclusions from it. The PSX had dedicated hardware for geometry transforms, video decoding, sound processing, and rasterizing. The CPU was used for game logic and queuing up the render pipeline. So it's not like all PlayStation developers were doing black magic in every game, they were using a lot of dedicated hardware with well known and relatively modest and fixed constraints (NTSC/PAL, stereo audio, and relatively small frame buffers).

It's interesting you picked the PSX as your exemplar because it's CPU/GPU/MDEC and audio processor were meant to be black boxes so developers didn't have to code to bare metal. The IO stack was much shorter and the OS (such as it was) was single tasking, single threaded, and didn't have any networking.

Slowdowns in modern systems are much more complicated that a simplistic "inefficient code makes them slow". There's hundreds of small stupid latencies all over the place in modern systems. The USB and Bluetooth stacks are filled with little latencies, retransmissions, and just wait loops. Unless your inefficient code is full of accidentally quadratic loops it's usually compounded latencies making systems "feel slow".

Re: Spectre mitigations murder userspace performance

#202

Post by msbarnett »

thrower123 wrote: post #37
dijit wrote: post #16

Earlier quoted context omitted.

The scope of the potential damage is rather huge and can't really be overstated. It's akin to handing over your entire working OS memory to a person, complete with all encryption keys, session tokens and whatever documents you're working on. Potentially, anyway. The working proof-of-concept attacks I've seen use a lot of CPU to read memory and they read slowly, but those are proof-of-concepts and it would not be terr…

Has there ever been a real-world attack of this type? All kinds of things are possible, but you don't cut your leg off because theoretically you might possibly one day get gangrene from an ingrown toenail.

There are working proof of concept attacks. The only reason you don’t hear more about this is that the mitigations being complained about here are universally enabled in the most vulnerable targets, like cloud hosts.

Otherwise it would be pretty trivial to weaponize the original demonstration, deploy an image to AWS or Google Cloud and read out all your neighbours’ secrets.

The success of the mitigations in rendering these attacks unworkable is literally the only reason people are under the mistaken impression that the cost of the mitigations isn’t worth it “because these attacks don’t happen”.

Re: Spectre mitigations murder userspace performance

#203

Post by msbarnett »

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.

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

Use a browser that isolates the JS engine in its own process and leave spectre mitigations enabled rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?

Re: Spectre mitigations murder userspace performance

#204

Post by pjmlp »

msbarnett wrote: post #194
pjmlp wrote: post #188

Earlier quoted context omitted.

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

You would assume incorrectly.

How would Spectre exploit UNIX message boxes then?

Re: Spectre mitigations murder userspace performance

#205

Post by amelius »

rbanffy wrote: post #189
amelius wrote: post #80

Earlier quoted context omitted.

What if your system is virtualized?

If you are pinned to a core, as non burstable instances should be, you are still pretty much vulnerable. Having noisy neighbours will pollute caches and make extracting data harder, but, eventually, everything will leak out. I’ve been thinking what would happen if cores would be pinned to separate security domains - all kernel processes run on one set of cores and user processes on others. I imagine microkernel OSs c…

Isn't the entire memory hierarchy (caches) part of the problem?

Re: Spectre mitigations murder userspace performance

#206

Post by yyyk »

kd913 wrote: post #19

Is this agnostic to hardware? I thought Intel/AMD had different strategies regarding variants of spectre with AMD having specific solutions of retpoline. Without knowing the hardware, what is the point of the performance comparison?

>Is this agnostic to hardware?

Not agnostic at all. Newer processors have less bugs to work around, and instructions to speed up the workarounds, so the performance impact is smaller:

https://www.phoronix.com/scan.php?page=article&item=3-years-...

The author's hardware is uniquely susceptible - Skylake is old enough to suggest Meltdown mitigation (the new Intel processors and of course AMD don't require it) in addition to Spectre mitigation, yet it's new enough to use indirect branching more thoroughly than Broadwell.

If the author had older or newer hardware the performance effect would have been smaller.

* It might be noted that there were Intel models betwen Skylake and the current which were still susceptible to meltdown. Even those had a smaller performance impact:

https://www.pcgamesn.com/intel-security-patch-performance

Re: Spectre mitigations murder userspace performance

#207

Post by msbarnett »

pjmlp wrote: post #204
msbarnett wrote: post #194

Earlier quoted context omitted.

You would assume incorrectly.

How would Spectre exploit UNIX message boxes then?

Multiple Spectre variants (RDCL, RSRR, Lazy FP state restore, SpectreRSB) bypass process boundaries. It doesn’t matter what IPC mechanism you use, they can read arbitrary privileged memory no matter who owns it.

IPC really has nothing to do with anything, Spectre-wise; you don’t have to be using any IPC mechanism in either the attacker or attackee process to be vulnerable to these variants.

Re: Spectre mitigations murder userspace performance

#208

Post by SkyMarshal »

gruez wrote: post #196
hutzlibu wrote: post #127

Earlier quoted context omitted.

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

Re: Spectre mitigations murder userspace performance

#210

Post by SkyMarshal »

msbarnett wrote: post #203
SkyMarshal wrote: post #192

Earlier quoted context omitted.

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.

> If you have a better approach that accomplishes both of those objectives, do tell. Use a browser that isolates the JS engine in its own process and leave spectre mitigations enabled rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?

>Use a browser that isolates the JS engine in its own process

Definitely. All for that.

>and leave spectre mitigations enabled

I do that anyway. The performance cost is unnoticeable to my normal workloads.

>rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?

I'll continue doing this too, largely because I want to see what's going on behind the scenes on all the websites I visit. Useful for me to see it all, especially as it changes over time as you observe.

That said, Easylist and Privacylist are also great if you'd rather crowd-source the finger-in-dike-hole-plugging.

Post reply on HN