Reply to post:

" Intel on the other hand is wanting the security fix to be opt-in, which as Linus rightfully states as insane."

AFAICS Intel seem to be saying that, at least in the short term, their only option is a performance-draining one which they want to make opt-in. That doesn't preclude them having a better option in the long term, even if they have no present intention and are forced into it. A flag which says "I'm fixed" could mean fixed by having opted in on the immediate option but fixed by a redesign in the better, long term version.

The boot-time, user-settable flag would be the choice of speed vs security. With a fixed design this would become a no-op because the user would have security and speed.

The run-time, read-only flag would simply tell, if clear, that any mitigation needed would have to be in S/W. If set the S/W itself would have any indication of whether it was set as a user choice or by the redesign.

This would only work if, speed issue apart, the microcode and hardware fixes were equivalent from the user point of view. Intel clearly aren't going to be able to deliver the full, no speed penalty fix that Linus - and the rest of us - want in the short term via microcode changes. If, however, they were able to deliver the "I'm fixed" flag that Linus asks for as part of the short term microcode fix then they'd be wise to listen to him. In the meantime Linus - and the rest of us - are going to have to live with what can be delivered in firmware changes to microcode.