For Meltdown, they aren't. It was silly to do lazy validation of memory accesses and Intel fixed that.
For Spectre, you can't really have a high performance chip that isn't vulnerable to it in theory. A processor can't read your mind and know which code within a process should be able to communicate with which data within the process unless you tell it. You could just go to strict in order but that's taking a huge performance hit. Programmers cominging secure information and JITs running untrusted code within the same process will have to work to make sure they're not vulnerable to Spectre going forward.
> For Spectre, you can't really have a high performance chip that isn't vulnerable to it in theory.
You could if you had a fully transactional cache such that branch misses could be rolled back. It's highly non-trivial and likely far too expensive in die space to justify, but theoretically solvable.
But I think realistically CPUs are just going to say "processes are the only security boundary we offer" and leave it at that. Which puts things like WASM in a very questionable spot (particularly things like WASM in the kernel), but Intel & AMD probably don't care about that too much. For web browsers all the major ones just gave up on in-process sandboxing and that's why we have things like per-iframe process sandboxes now ( and then reduced privileges in-process iframes with the 'sandbox' attribute: https://caniuse.com/?search=sandbox )
For Spectre, you can't really have a high performance chip that isn't vulnerable to it in theory. A processor can't read your mind and know which code within a process should be able to communicate with which data within the process unless you tell it. You could just go to strict in order but that's taking a huge performance hit. Programmers cominging secure information and JITs running untrusted code within the same process will have to work to make sure they're not vulnerable to Spectre going forward.