If Mitigations Weren't Already Bad Enough: Slow Build Times Now Lead To An Unoptimized Intel LVI Pass

[Volta]

Why do most of us care about these mitigations? [cut the stupid part out], but the only place that should run untrusted code on a desktop is the browser.

That's why we care about mitigations.

[Guest]

Except in many cases the hackers are nation states who own the prisons and are looking to fill them with their hacking victims.

Unfortunately it seems, India has become one such nation. The present government is not good at hacking, but they are good at abusing their power to throw innocent people in jail.

[Guest]

If you leave your car open, no one's going to jail, but your car disappears.

Well if the thieves are caught with evidence that they stole your car, they will go to jail. Most likely.

[mzs.112000]

Welp, looks like it's time to get a POWER computer(my taste says Talos, budget says old PowerMac G5).
Too bad there are no POWER laptops...

[hotaru]

Welp, looks like it's time to get a POWER computer(my taste says Talos, budget says old PowerMac G5).
Too bad there are no POWER laptops...

while POWER is better than Intel when it comes to vulnerabilities, that's a pretty low bar to pass. it's still significantly worse than AMD or ARM: https://www.ibm.com/blogs/psirt/pote...-power-family/

[patstew]

That's why we care about mitigations.

But as I said those can be mitigated by the browser / JIT engine without affecting the rest of the system.

[patstew]

In short - don't argue about security based on already documented attacks. It's not them that are the main threat. It's the attacks that are currently been developed - the flawed machines will not go away in a good many years.

Exactly, and most kernels have some critical flaw that allows privilege escalation. There's almost certainly loads more that aren't publicly known. You can't safely run untrusted code, and once you've accepted that, these mitigations are shutting the stable door after the horse has bolted.
For a recent example, this didn't warrant the same phoronix coverage these CPU issues get but it's much more serious https://www.thezdi.com/blog/2020/4/8...m-verification

[hotaru]

Exactly, and most kernels have some critical flaw that allows privilege escalation.

how many of those flaws can be exploited by sandboxed JavaScript running in a browser?

For a recent example, this didn't warrant the same phoronix coverage these CPU issues get but it's much more serious https://www.thezdi.com/blog/2020/4/8...m-verification

JavaScript in a browser doesn't have have access to run eBPF programs without some other vulnerability, but it can exploit flaws in the CPU even if there aren't any software vulnerabilities.

There's almost certainly loads more that aren't publicly known. You can't safely run untrusted code, and once you've accepted that, these mitigations are shutting the stable door after the horse has bolted.

the time to make that argument was in 1995, when JavaScript was first introduced. it's too late now. running untrusted code has become a core part of how web browsers work, and that's not going to change any time soon.

[patstew]

how many of those flaws can be exploited by sandboxed JavaScript running in a browser?

I addressed this in my first reply, my argument is that mitigations should be applied in a browser that JIT compiles javascript, but that's no reason to slow down the whole system. The simple measure of denying all access to high resolution timers is enough to cut out 99% of these side channel issues, including the ones that haven't been discovered yet. Javascript doesn't have multiple threads so you can't make your own timers, unless you're on a network with a ridiculously low latency to an attacker controlled machine. That could be mitigated too, e.g. by adding a tiny bit of random jitter to javascript requests, but I'm skeptical that it's practical in the first place.
And if that's insufficient the browser could opt in to kernel level mitigations.
Obviously Javascript also can't access x86 instructions like RDRAND or special CPU registers either, so some recent issues are impossible to exploit from javascript anyway.

[hotaru]

The simple measure of denying all access to high resolution timers is enough to cut out 99% of these side channel issues, including the ones that haven't been discovered yet. Javascript doesn't have multiple threads so you can't make your own timers, unless you're on a network with a ridiculously low latency to an attacker controlled machine. That could be mitigated too, e.g. by adding a tiny bit of random jitter to javascript requests, but I'm skeptical that it's practical in the first place.

denying access to high resolution timers isn't enough.

JavaScript does have multiple threads.

there are ways to work around jitter, too.

And if that's insufficient the browser could opt in to kernel level mitigations.

the browser can't opt in to kernel level mitigations that are forcibly disabled or don't exist.

Obviously Javascript also can't access x86 instructions like RDRAND or special CPU registers either, so some recent issues are impossible to exploit from javascript anyway.

so SRBDS is probably not exploitable from JavaScript without some sort of software vulnerability to execute arbitrary code. unfortunately, that still leaves a lot of other vulnerabilities that can be exploited even if your browser doesn't have any bugs.