The part I find really scary with all of this, as Keith is saying, we are fixing hardware with software, meaning someone can "unpatch" the change.

I don't believe that processor microcode can be "unpatched" nor can it easily be patched again to undo what was done.

However, what I see as the real issue with all of this is the microcode updates allow software developers to choose whether or not they take advantage of the new IBPB, IBRS, STIBP, and or the retpoline changes.

What this means is going forward we are at the mercy of the developers to believe they made the right choice, if they even had a clue to begin with. (by that I mean a developer wasn't a noob, or didn't use some point and click development tool).

Remember the days when you could download a virus creation tool that would allow you to make some selections and it would spit out an .exe that would crash a system and made a world full of script kiddies happy? I see something similar to that coming for this. Someone will build a tool to check if X particular piece of code is protected and using memory the way it should be or not.

Until compilers get updated, and we have some visual confirmation or something that the running code has been recompiled with the new compiler that enforces use of these new microcode instructions, we're kind of screwed.

I didn't have a whole lot of trust in Microsoft before, and now I really don't. I think they will use this to their advantage to force people to upgrade to 10 (notice they said "a few win 10 workloads" but "most" win 7 and 8 workloads?)