It is sad that the solution is to cripple the software. I hope that these workarounds will be relegated to compatibility issues in the future as the underlying hardware is eventually fixed.
No software was crippled here. Process isolation is arguably the way it should have always been in the first place. Hell, rebrand it as "hardware accelerated sandboxing" and now it's an obviously superior approach, right? ;)
But either way nothing was actually "crippled", and if anything the reverse is true. They are un-crippling aspects of JavaScript (like re-introducing SharedArrayBuffer).
I suppose this is where I realise I don't actually understand the underlying issue. If it is a software issue, why is there so much blame directed to the hardware vendors?
It's a hardware issue - ie. it is caused by compromises hardware made to speed up execution times.
Because we're stuck with the hardware we have, we can make software fixes - however they are going to require either slowing down or removing certain features until we get a hardware fix for the issue.
thank you. I read in another comment that this isn't an issue with process isolation of memory (which I originally thought), its an issue with the isolation of memory within the process - would you say that is a good summarisation? i.e. the hardware is working as designed, but the software is expecting guarantees that the hardware never promised?
Spectre only allows access to the process' own address space, yes. But Meltdown works across processes, so hardware manufacturers (and specifically Intel) have definitely dropped the ball there, as well.
The problem is the same. The fact that we can hide most of the kernel memory is handy, but it shouldn't be up to the software to do that - user processes shouldn't be able to access memory that pagefaults. Definitely a dropped ball by the manufacturer
Not the same. As you say, a process should not be able to access pages that are protected by hardware permission bits. That's exactly the issue with meltdown.
Spectre is different, it allows reading pages that a process would already have hardware permission to read[1] but actual permission is enforced at the software level (i.e. software as opposed to hardware bound checking).
[1] It is possible to construct spectre v1 attacks against other processes in some cases, but are much harder, low bandwidth and I do not think are yet shown to be practical.
> Not the same. As you say, a process should not be able to access pages that are protected by hardware permission bits. That's exactly the issue with meltdown.
Okay, but the hardware issue is pretty much exactly the same... the bug in hardware that enabled spectre is also what enabled meltdown.
The only reason we managed to fix this is by moving most of the kernel task memory out of the user page table - a software fix for something that the hardware should have been doing.
No, it is really a different bug. One is speculation around branches, the other one is speculation around hardware protection check (which is not implemented internally as a branch). In fact, while all OoO CPUs are vulnerable to spectre, not all of them are vulnerable to meltdown because, for whatever reason, their designers decided not to speculate around hardware checks (possibly because the check could be implemented efficiently in the critical path given their L1 cache design).
I'm not an hardware designer, but likely both instances of speculation use the same snapshot and rollback logic, but that's about it.
I think that's a matter of debate - I personally don't think hardware should allow any sort of memory leakage in an otherwise safe language. It also renders any attempt to move critical software out of the kernel and into user-space very dangerous.
With meltdown, the issue was definitely a failure of the hardware vendors obligation -> Kernel memory should definitely not be exposed to the process and yet it was.
I would say such a justification is somewhat of a cop-out by the hardware vendors.
