Google Engineers Argue For Linux "ASI" To Better Deal With Speculative Execution Attacks

[Mike Frett]

Hear me out for a second...would it not be better to fix this at the source, the CPU? I think it's better to treat the cause and not just put band-aids on it. I'm talking about future hardware of course.

[Anux]

Hear me out for a second...would it not be better to fix this at the source, the CPU? I think it's better to treat the cause and not just put band-aids on it. I'm talking about future hardware of course.

Yes it would but it's impossible because some of these are fundamental hardware design flaws.

[Hafting]

But there's still Javascript and Wasm that could run on your web browser.

There are already javascript filters that cut ads and bitcoin miners. Blocking some more is not hard. And there is noscript too.

[Hafting]

Hear me out for a second...would it not be better to fix this at the source, the CPU? I think it's better to treat the cause and not just put band-aids on it. I'm talking about future hardware of course.

Sure. If the cpu is going to "speculate", then the speculation should run within the memory protection system just like real execution. So, no speculative access to memory you cannot read directly. This solves such problems, at the price of some more silicon. And we donˋt get an unnecessarily handicapped kernel.

Obviously, this fix will only be available with future CPUs. But how long do we keep a cpu anyway?

[NobodyXu]

There are already javascript filters that cut ads and bitcoin miners. Blocking some more is not hard. And there is noscript too.

You can't block every JS as that will break functionalities for some websites.

[OmniNegro]

You can't block every JS as that will break functionalities for some websites.

Break functionalities for some websites... You do realize the discussion is about speculative execution and mitigation?

I understand what you are saying, but there was never a perfect world free of imperfect things. Life goes on.

[Anux]

You can't block every JS as that will break functionalities for some websites.

Lets be honest, it's most websites.

I already block as much as possible while still maintaining usable websites but how should one know if the allowed scripts are trustworthy?

[Vorpal]

Obviously, this fix will only be available with future CPUs. But how long do we keep a cpu anyway?

I usually replace my computers after 10+ years (because they can no longer do the things I want to do). I would keep them even longer if they still delivered acceptable performance. So fairly long.

[Vorpal]

Lets be honest, it's most websites.

I already block as much as possible while still maintaining usable websites but how should one know if the allowed scripts are trustworthy?

I would love if it was possible to only apply mitigations to certain processes. I.e. Windows VMs and the browser. Unfortunately for many of these issues that is not feasible, it is all or nothing, as long as the kernel is shared. I suspect (after thinking about it for 10 seconds, so take it with a grain of salt) that meltdown might be possible to mitigate per process in theory. Spectre and retbleed probably not.

[andyprough]

Scroogle has done a bang up job on browser security the past few years, with only like 30 or 40 zero day exploits. Why not just hand all kernel security over to them, what could possibly go wrong? It's not like they would stick a PRISM-style backdoor into everyone's running kernel to make it easier for their spy agency partners to do all their nasty tricks.