> 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.
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.