Hacker News Reader

And here[1] is Woodhouse's coherent latest reply as of a couple hours ago on the issue, which explains for all us in the peanut gallery (his words, which I think are spot on) exactly what this is about, why it's included, how it actually affects the situation, why it was put forth at all, etc.

It appears much less sinister than Linus was insinuating, but Linus has yet to reply.

1: http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html

View on HN

That's an interesting summary but I predict that Linus will destroy him for completely avoiding the hard question: why the fuck IBRS_ALL would not be on by default on future "fixed" chips, if on such CPU it would not be somehow crappy. And the risk of it becoming architectural (with that absurd default) is insane too.

Why would he do that? I completely agree with him on that, and I already told him I've been pushing back on it since I first heard about it a few weeks ago. Although there are technical reasons why we might need IBRS_ALL as a stop-gap before we can get to a proper solution, we bloody well ought to have line-of-sight to a proper solution in the same way that RDCL_NO says "it's OK, we fixed it" for Meltdown.

But that's a separate topic. As I explicitly said, I limited that answer to the things we can do on current hardware.

Reply on news.ycombinator.com