Hacker News Reader

Comment by atemerev | Hacker News Reader

Spectre/Meltdown is a serious problem, but they matter only in shared environments (virtual hosting with multiple accounts per physical machine).

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware with no code from other users running).

P.S. https://make-linux-fast-again.com/

View on HN

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware with no code from other users running).

Most desktops and laptops run a boatload of untrusted code in the form of JavaScript.

How about enabling mitigations in Javascript engines?

There aren't such mitigations to enable. There aren't even purely software kernel-level mitiations.

> There aren't even purely software kernel-level mitiations.

Some are there, otherwise they couldn't be disabled in Linux kernel for faster performance. Which means that they could be enabled on demand.

Some are there, yes, but they're insufficient to provide security. You need both them, and the microcode changes, and to disable HT. I'm not sure what if anything the software changes do alone, they may mitigate some of the attacks, but not all of them.

why do you think you control that?

apple tries, and even then people already managed to run code via pdf engines; on android it's at least more clear you have no control.

You probably have apps in your phone runnig rigth now that ship with their own JS engine for advertising purposes. Do you expect them to have all the necessary safeguards?

Apple did just that in Safari on macOS.

Apple attempted to do that (I believe it was the Google security team’s MDS writeup that referred to it as a “Herculean effort” on the WebKit team’s part), but even they fell short.

The position that all of the browser vendors have landed on at this point is that mitigating this class of attacks in the browser is simply not possible.

> ...but even they fell short.

Can you please elaborate? Did these effort fail completely or is it that if you use your browser a certain way then you can never be protected? (Which implies that using it another way would be safe.)

per the v8 team, efforts to fully secure the JS JIT engine are simply infeasible against some Spectre class attacks:

> Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.

You talking about the Update they released some days ago? Or those who are several months old?

Apple released a new one for the newest vulnerability so they didn’t have to reduce the performance of macOS by ~30%.

I’m talking about the Chrome v8 team’s white paper on why they are giving up on trying to mitigate Spectre class attacks in software, which mentions, among other issues:

Apple released an update with some mitigations, but they are by no means perfect, and their message is that if you want to truly be safe, either don’t run JS, or disable hyperthreading.

None of these have ben shown to work with a real-world exploit in JS. There is just too much noise going on.

I'm getting so tired over how oveblown this is getting I was thinking of laying down a $1k bet if anybody will take me up on it, but I dont't think anybody would because it likely isnt possible.

Most of the hype seems to be drive by some Intel gotcha hate.

Here's a JS speculative read example straight from the original meltdown paper turned into a PoC checker: https://terjanq.github.io/meltdown-checker/app.js I accept PayPal ;-)

(Of course this depend on your definition of a "real world exploit", but this does show that you can cross boundaries of a type system.)

You know exactly what you are looking for at that exact address, without nothing else running and polluting the cache, and you are given an extended amount of time to attack.

"you can cross boundaries of a type system" is not even close. In no world could this cod be used to gather useful data on a running system. You are literally just reading from an array you had setup.

It is well known in the academic literature that attacks "mitigated" by "there's too much noise, you'll have to try too many times, you can attack it in the lab but not on a real machine" are not mitigated at all. See for instance https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf .

A practical case where you have an extended amount of time to attack are when you're an ad in a background tab of a website with interesting credentials.

> P.S. https://make-linux-fast-again.com/

I like this website because, like its namesake, it promotes a simplistic solution to a symptom of an underlying problem, as if the symptom were itself the problem, in a manner that appeals to those who believe that a just world only has simple problems with simple solutions, and with no discussion of unintended consequences and serious security risks and no consideration of why those who have actually studied the problem in depth advocate different, more complicated solutions.

It does exist in single user environments. What about a desktop/phone that runs untrusted code? e.g. every browser that supports JavaScript.

Yes, and this code is contained within the Javascript engine. Mitigations could be enabled only there.

Disabling HT can't be done per-process. Since per-frame browser processes need to be protected from one another, you can't even run two browser processes on the same core in HT. And scheduling a browser process while leaving the second HT slot on the same core empty is even slower than turning HT off.

Somebody please explain to me why ripping out the JS JIT wouldn't work.

In the most recent discussion of this it was reported that is no longer an easy option with Firefox: https://news.ycombinator.com/item?id=20012750 There's also a general impression that would be too slow for many web pages, and that comment noted it took minutes for logins using JavaScript cryptography to execute.

It seems to me that most people will be willing to pay for slower js as opposed to an overall slower system.

Does it even need to be slower? Almost every single website out there is not a javascript app and so side channel attacks can be mitigated by simply having an rlimit-style CPU time limit after say a user action on a tab.

Browsers rely on kernel/hardware mitigations. Google people even claimed it's impossible to fully mitigate those vulnerabilities in existing Javascript implementation in Chrome.

It's the job of the OS to make sure one process can't read the memory of another process. What you're saying is that should now be the responsibility of the JavaScript engine as well as the OS.

Is there a way to do the same for windows?

Reply on news.ycombinator.com