Not really with you on this one
Spectre and Meltdown are generally exploitation of poorly coded operating system kernels.
Speculative execution is a critical CPU design feature. Compare a Raspberry Pi vs a similar board running an ARM core with the feature. The performance difference is phenomenal. It also is bloody insecure if the operating system doesn't flush the pipeline on system calls.
System calls have always been and always will be expensive on general purpose operating systems. Consider that it requires a great deal of setup, serialization, etc of each call. It also requires processing of a software interrupt or an exception to break into the kernel. Transferring data of any consequence back is ridiculously expensive as it requires traversing the differences between the LDT and the GDT or maintaining multiple LDTs for the same data.
We as operating system designers made a conscientious choice to ignore the state of the speculative execution pipeline a long time ago. This was done because the cost of flushing it was too high and we simply did not see it as being a real security risk. Most JavaScript engines exploit the hell out of the state of the pipeline to avoid cache coherence issues between threads on different cores to avoid negotiating locks on memory which are way more expensive to process than normal system calls.
The solution to the problem is 100% operating system. VMware and other virtualization vendors need to perform access control during task swaps to identify whether to flush the pipeline between threads. This makes a lot of sense because in circumstances where virtual machines are reserving entire cores, there isn't much benefit to a flush of the pipeline on system calls, Of course VMware writes some of the most horrifying code with regards to security, so I figure they should probably just flush the pipeline and take the performance hit. There's no chance they can possibly get access control right.
Web browser vendors need to update their JavaScript JITs to explicitly avoid production of code that can exploit this. This is very doable, but every browser vendor will take a pretty serious hit performance wise. Stack on that issues regarding WebGL and WebCL, it could be a difficult challenge. Either way, there's no possible reason we should have a problem ensuring that attacks can't be launched from websites.
Server managers need to turn on Windows Smart Screen or similar to ensure that they don't run stuff that has the exploit present. As will other naughty software, a well placed time-bomb should trick security labs everywhere. Sandboxes which move the time forward to try and trigger time bombs for ages because the naughty software only needs to explode during a window of time to get around that.
Anti-virus needs to be up to date.
I in no way blame Intel, TI, ARM or any other hardware vendor for this cock-up. This is 1000% Microsoft, Linus, etc... and even then I don't blame them. I had to update 4 operating system I've written to flush the pipelines between threads following this exploit. It was my choice in the first place to skip cleaning up my shit between syscalls.
Now, AMD style memory encryption IS NOT!!!! read... IS NOT!!! a solution to this. I have over 100,000 lines of code in my project I'm working on right now. It's 100% multi-tennant and it's all in a single process and has no separation or possibility of separation on AMD processors via memory encryption. In fact, if I tried using that feature, it would be an absolute cluster-fuck.
I have gone back to update my code to handle role based permissions a lot better.
So... in the end... these are not processor based security vulnerabilities. We simply have had a bonus performance boost by coding operating systems badly for a long time. We now lost part of that boost for now... but there's absolutely no reason that operating system developers can't design solutions to identify when to selectively flush the pipelines. Then we'll get the performance back.
P.S. - I don't think QNX is having any problems because of this.