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.
Spectre not so much.