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?)---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)