Hacker News Reader

Comment by bcantrill | Hacker News Reader

I was surprised that this wasn't already submitted -- and then surprised again that it's not being upvoted. To give some color: this doc contains the first public disclosure of some new MSRs being added to allow system software to help mitigate Spectre. In particular, these are the controls to limit speculation including Indirect Branch Restricted Speculation (IBRS) to restrict speculation of indirect branches; Single Thread Indirect Branch Predictors (STIBP) to prevent indirect branch predictions from being controlled by the sibling hyperthread (!!) and Indirect Branch Predictor Barrier (IBPB) to limit influence on later indirect branch predictions. For those who need to implement system software support for the new microcode, this is very important information!

View on HN

Actually, thanks to the messy uncoördinated premature disclosure, the MSRs became publicly known yesterday through code comments, commit messages, Google Docs, and linux-kernel mailing list discussions.

* https://news.ycombinator.com/item?id=16072009

* https://lkml.org/lkml/2018/1/4/432

* https://news.ycombinator.com/item?id=16072775

* https://lkml.org/lkml/2018/1/4/615

* https://news.ycombinator.com/item?id=16072806

* https://news.ycombinator.com/item?id=16075082

A more pertinent observation is that this is the sort of technical paper that Intel should have published before the press releases that yielded such a backlash.

* https://news.ycombinator.com/item?id=16076601

* https://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588)

It's not due to the premature disclosure.

As far as Linux is concerned, the disclosure of Spectre and the hardware mitigations was uncoordinated by design. During the embargo period, distros were kept siloed and each more or less left on its own, assuming they were part of the early disclosure at all. This sucks, but until the embargo was lifted we were pretty much forced to play along. We did not even know who knew what, so we couldn't do anything about it.

As a result, distros all differ in the amount of tunables that they provide, in the exact behavior, and in the performance hit that you can expect from fixing CVE-2017-5715. Assuming it's fixed at all (it's not in either Debian or Fedora, for example).

The silver lining is that all discussions on the design choices for the fixes are going to be public. Anyway, based on some tweets from Alex Ionescu, it seems that these MSRs are what Windows uses (and RHEL as well, which is what I worked on).

You are talking about the phase where stuff was not publicly known. I talked about the point of it becoming publicly known.

The way that it actually happened, rather than being the way that Intel expected it to happen with this paper all nicely ready on the first day (like Google's happened to be ahead of time), was pretty clearly unfortunately very much down to the premature disclosure. Witness what Paul Turner said (hyperlinked from one of the aforegiven discussions) about Google's and Intel's original goals for the week, for example.

One can speculate about an alternative universe where Linus Torvalds had this to read before the press releases. There's a whole chapter that addresses the points that he raised.

* https://lkml.org/lkml/2018/1/3/797 (https://news.ycombinator.com/item?id=16066968)

It is interesting that you bring up M. Ionescu. I'll see M. Cantrill's surprise at no-one commenting on Intel's paper, albeit that this is becoming less and less true by the minute by dint of posts like yours and mine, and I'll raise him no-one on Hacker News commenting at all on Microsoft; even though it was a more prominent topic of discussion in my workplace today (when the office systems administrator found out that updates were not happening) than any Linux machine or BSD. (-:

* https://news.ycombinator.com/item?id=16076660

I am sure Linus knew about this before, just like I was disclosed most of the things in the paper (in .pptx format).

Based on how the early disclosure was handled, I would have expected the same mess even without the emergency premature lifting of the embargo. Maybe a little less scrambling, but the same confusion, plenty of discussions on 0-day and no fixes for noncommercial distros. Everything else is wishful thinking.

I don't know what you mean by "first public disclosure" but these mitigations were already disclosed yesterday when Linux patch with their support was submitted: https://lkml.org/lkml/2018/1/4/615

People had been waiting on more details of the Intel microcode update, for example from kernel mailing list yesterday mid-day:

https://lkml.org/lkml/2018/1/4/696

Are programs running on SmartOS zones vulnerable to any of the latest discoveries?

Yes.

Any comments on niagra t1 & t2 related to these methods?

Sparc didn't get out of order until T4 unless I'm mistaken. (Assuming speculative execution was added about the same time.)

ldxa asi non-faulting load ultasparc-i circa '96

Reply on news.ycombinator.com