I'm less familiar with Spectre than Meltdown but part of the issue to me seemed to be that everything hinged on the principal of memory isolation. To the point

I'm less familiar with Spectre than Meltdown but part of the issue to me seemed to be that everything hinged on the principal of memory isolation. To the point where all of physical memory was mapped from the kernel which was mapped to the user address space. It felt to me like having 1 great big lock and assuming it couldn't be broken. I get that when you make the assumption that you cannot depend on memory isolation a lot goes out the window, but could there be a more layered approach that lessens the damage done when some assumption like that is challenged or is it appropriate to wait until that time to make changes? The amount of damage possible when that assumption is chosen to be false seems to warrant considering changing the way process memory is mapped. This is at a software level but its similar to what you were saying, when is speed and performance going to be sacrificed for preemptive security measures? I'm sure that it already is in some ways since all security has a performance hit, but allocating processes and virtual memory is such a core feature of the kernel that I can imagine the performance hit could be significant (or was it just laziness to map all of physical memory to the kernel address space?)