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

181–190 of 294 posts

Re: Spectre mitigations murder userspace performance

#181

Post by Natsu »

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…

> Microsoft learned next to nothing from the browser wars lawsuit.

That's been true since the very beginning.

I very nearly filed papers to oppose class council in one of the state lawsuits on the basis that the proposed settlement was calculated to create a new antitrust injury to the class.

But I didn't because I was young and pro se and there was no way for me to afford or find representation. If I had to do it again I would've filed pro se requesting that they reject the settlement on that basis and appoint a guardian ad litem to roll the dice anyway.

Re: Spectre mitigations murder userspace performance

#182

Post by msbarnett »

SkyMarshal wrote: post #155
gruez wrote: post #98

Earlier quoted context omitted.

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.

I disagree. I'm not just pulling this out of my ass, I've been doing exactly this for years, I can't remember how long. It works fine. >you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits. The key here is that when you're deciding whether to whitelist a JS import, and you don't know what it is and don't want to take the time to look it up, then whitelist…

> 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-inspect minimized JS, so this eventually turns into semi-blind faith.

And permanently whitelisting URIs is pure security theatre; that file could contain anything, next request.

Re: Spectre mitigations murder userspace performance

#183

Post by rbanffy »

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…

> Has there ever been a large company in IT that didn't turn absolutely evil as soon as the opportunity presented itself?

If turning evil increases shareholder value, it’s their fiduciary duty to do so.

Re: Spectre mitigations murder userspace performance

#184

Post by rbanffy »

revscat wrote: post #166
formerly_proven wrote: post #92

Earlier quoted context omitted.

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

The behaviors described here are intrinsic to capitalism, and are not peculiar to any individual company. The executives quoted here are simply describing the waters they swim in. But they are only one fish in the sea that is liberal governance. The system is the problem, not Microsoft.

This system will cause any publicly traded company to behave like a sociopath and limit career paths for non-sociopaths who are unwilling to break (or bend) the law to further their agendas.

Re: Spectre mitigations murder userspace performance

#185

Post by Barrin92 »

is there an actual number one can attach to at how much risk this puts me in practice? Say I'm an average user, writing softare, using the web, is it one in a million on any given day, on in a thousand? It's hard make judgements about whether to make these performance/security trade-offs without any real sense of how dangerous it is.

Re: Spectre mitigations murder userspace performance

#186

Post by dijit »

staticassertion wrote: post #165
dijit wrote: post #36

Earlier quoted context omitted.

Three main things here: 1) we can’t trust people to categorise their own apps because the incentive for performance over security is a trade off we’ve all made time and time again. 2) efforts to address mandatory access controls have a coloured history here: selinux and apparmor both have very low adoption rates no matter your personal anecdotes. 3) These mitigation’s are so thorough that it would be more expensive o…

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

Re: Spectre mitigations murder userspace performance

#187

Post by pjmlp »

usrusr wrote: post #177
pjmlp wrote: post #70

Earlier quoted context omitted.

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.

Yeah, but in the context of games, most likely it means threaded code written in C or C++.

If anything Spectre has shown us that the only real mitigation is to go back to multiprocessing with IPC, with the extra hardware resources it entails, as the exploit exists regardless of the language for in-process memory.

Re: Spectre mitigations murder userspace performance

#188

Post by pjmlp »

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…

That would be only on the context of shmem, right?

I would assume other IPC mechanisms are safe from it.

Re: Spectre mitigations murder userspace performance

#189

Post by rbanffy »

amelius wrote: post #80
neilsimp1 wrote: post #2

`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a... .

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 could go that way much easier. If kernel and user space communicate only by messages and shared data, there’s no reason they’d need to even share an ISA.

Re: Spectre mitigations murder userspace performance

#190

Post by slver »

kyledrake wrote: post #180
slver wrote: post #171

Earlier quoted context omitted.

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

When you talk about performance hit, are you under the impression that moving this to the server side would be faster? No. So what is the alternative?

If you move everything to apps, apps become the vector.

If you ask for explicit ok online, it becomes like the cookie dialog. Pointless.

Offer an alternative.

Post reply on HN