> So perhaps it can't really be fixed with > software patches but indeed just 'mitigated'.
Note that these mitigations are only good against hackers and criminals - they have no effect on Intel, as long as the microcode is proprietary. And it doesn't matter if the it is factory loaded or upgraded.
I find it interesting that FSF et.al. take great pains to eliminate -not only proprietary code itself- but everything related to proprietary software (firmware blobs that run elsewhere, documentation referrals, suggestions, etc.) all the while there's this huge gaping hole in security by way of proprietary microcode. As long as the CPU rides on closed microcode - be it factory default or upgraded - there can be no security against the designer of that CPU.
For instance, there may be some "undocumented" (covert) instructions which can -for instance- break CPU ring boundaries. OTOH, an automated audit (simply dissassemble) of binary code would reveal all such out-of-band instructions. But then there's this recent "web browser" case of yours: Many open source browsers, supposedly audited by the community, _do_ covert background chattering. Then how can we depend on the possibility of catching usage of undocumented instructions in Intel's binary code base? E.g. anyone ever tried to dissassemble Intel software base (the whole lot of it) ever?
Also there may be other attack vectors that I can't think of right now. E.g. microcode "knocking" (as in "port knocking") possibility comes to mind. In this scenario, a specific juxtaposition and repetition of in-band opcodes can be used as a pass phrase to switch opcode interpretation one way or another, so that certain in-band opcodes suddenly start behaving differently. In that case no dissassembly would reveal such out-of-band instructions (because they are actually documented opcodes which just behave temporarily different). It would be near impossible to detect them.
And I'm sure there must be many other potential attack vectors that I can't think of right now. It really boils down to the fact that with a proprietary microcode/architecture, no higher level security scheme would hold water against Intel or any entity they cooperate with. With such an architecture, all the security measures, actual or perceived, goes out of the window. Sorry to say that.
So, gladly (or otherwise) accepting factory-loaded proprietary microcode, and yet rejecting an upgrade, is just... strange, if you ask me.
I can't see an easy way out of this dilemma unless Shakti team (RISC-V architecture) succeeds.
http://rise.cse.iitm.ac.in/shakti.html http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-December/015062.html
