Hacker News Reader

Comment by kllrnohj | Hacker News Reader

That was before spectre happened. Software isolated processes are now basically impossible to do. All the CPU microcode updates & workarounds are purely about fixing isolation between processes & rings that the CPU is aware of.

View on HN

>Software isolated processes are now basically impossible to do.

I don't think that's the case at all. To my understanding, software has always been capable of doing this just fine, but at a performance cost. So the mechanism was ported to hardware. Optimized implementations have proven to contain security issues. It's not that the security problems are unsolvable, it's that you can't just patch a broken CPU in the wild.

So we fall back to software implementations again, resulting in an overall perform decrease, but with the more correct security.

Specifically regarding speculative sidechannel attacks, your rebuttal does not address the comment you're replying to. kllrnohj is specifically noting that the mitigations for speculative sidechannel attacks rely on seeing the patterns of a preemptive operating system using the facilities expected by the hardware for that task.

Does that really follow? That purely software based solutions are doomed because hardware based solutions failed? Wasn't most fixes done at least partially in software?

I think you misunderstood. The hardware-based solutions are being fixed with various approaches whereas the software-based solutions nobody has any clue how to fix.

So much so that Chrome is giving up on software-isolation entirely and is rolling out even more process-based sandboxing https://www.chromium.org/Home/chromium-security/site-isolati...

Depends on how you define hardware and software. There are global workarounds that amount to crippling CPU behavior, to provide guarantees for code not written to be spectre safe. I guess that’s what you mean by “hardware”. But “software” approaches are localized mitigations to code written to avoid spectre attacks - and these localized mitigations use arch specific sequences to do so.

Another major problem with the software level mitigations is that they cost considerably more. Speculation fences cut performance to a small integer fraction of prior performance.

Then tell your SiP to do better.

On Arm the conditional speculation barrier couldn’t be more lightweight (CSDB).

Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach.

Threads and plugins have proven not to be the best ideas regarding implementing safe systems.

> Process-based sandboxing was too heavy in old hardware systems, but on modern ones is the best approach.

They actually started first with full process isolation, then realized that it had an outsize impact on performance, and now they're going back because the consequences for security are now known. There have been spectre-related patches going into chromium and v8 for the last few months, and they just keep coming, it's hard to overstate how much work must be done to have a decent probability of not being exposed to the known variants of these bugs in a software isolated system.

AFAIK, all the CPU microcode updates were for fixing Meltdown, not Spectre. Unless and until CPU manufacturers find a way to fix speculative execution for good, software-based mitigations would seem to be mandatory.

The problem is that "fixing speculative execution" means "stopping to make things faster in any measurable way". Given that the caches are there to make things 2 orders of magnitude faster, this is rather crippling.

The hardware based protections are the only boundary where you can "fix" speculative execution without slowing down your system by 100x.

The hardware boundaries effectively act as hints that say to the hardware "slowing down things by 100x here won't kill performance too badly -- we should turn off speculation for safety". Without those hints, everything needs to get that much slower.

Considering the hardware mitigations aren’t some magic bullet, but are a “big hammer” that cripples CPU OoO behavior in crrtain ways for everything, software mitigations don’t seem that unreasonable. Of course, “software mitigations” use CPU facilities as well, and can allow for making critical sections safe. In practice, it is well understood what code needs to be written in a spectre-safe way. The difficult question isnhow to write code to anticipate the next 10 varieties of speculation attacks...

I do not believe that it's impossible to fix Spectre in hardware without disabling speculation. How about we fix the state changes that Spectre detects. For example, we could have a buffer that stores evicted cache lines during speculation and restores them if a rollback is necessary. Yeah, it wouldn't be free, but it would be faster than disabling all speculation.

> For example, we could have a buffer that stores evicted cache lines during speculation and restores them if a rollback is necessary

The problem is that with pure software isolation, as being discussed here, every access is observable within the "same program", so every speedup would need to be rolled back.

With hardware boundaries, you know which speculations to roll back (or just avoid doing), so you can put a fix in silicon.

I'm talking about a hardware mitigation that would allow software isolation to work again, without disabling speculation.

I understand that. You cannot make this work, because in the case of pure software isolation, any instruction can theoretically be used to snoop on any other instruction. That means speculation can theoretically be detectable if it speeds up anything.

Unfortunately, this is not correct. Intel and AMD exposed MSRs for the Indirect Branch Prediction Buffer (variant 2), Indirect Branch Restricted Speculation (variant 2), and Memory Disambiguation Disable (variant 4). Variant 1 is unfixed. Variant 3 is meltdown.

AMD also pushed firmware updates, and they weren't affected by Meltdown.

Do you have a link to the firmware update announcement? Are there patch notes?

This is the latest I've heard about it: https://arstechnica.com/gadgets/2018/04/latest-windows-updat... I think the firmware generally comes from vendors, which for personal PCs means motherboard manufacturers. I did find this linked from an older Verge article: https://www.amd.com/en/corporate/security-updates

Thanks for the links. But the Ars link seems to confirm that all these mitigations need to be done in software, and that the firmware updates merely give the OS the hooks necessary to implement their own mitigations (implying that application software didn't get or need any help from the CPU in applying mitigations). And if all this is being done in software anyway, then it would seem to suggest that should at least partially suffice for a scheme like the OP's (someone who knows more about what these hooks actually do should say more). I'm not sure whether that means it's as secure in practice as conventional OSes--naively we should expect that it's not until proven otherwise--but it also appears to be a far cry from the above claim that "software isolated processes are now basically impossible to do", which, even if true, seems true as well for the software we already have.

Imagine you have a BASIC interpreter with a million cooperative threads. Can you write a BASIC program using spectre to break from one thread to another?

“break”? no, but spectre is a confidentiality attack, and not even the only confidentiality attack that can be done...

yes you could, but the noise floor won’t be great

Reply on news.ycombinator.com