4 ms·

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 pu

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!

frik 9y ago
Does this mean Hyperthreading as we know it basically gets almost useless because of perf degeneration? Anyway it's shocking that all these things were possible, and Intel didn't care about security for 2 decades (since 1995).
mzs 9y ago
Any comments on niagra t1 & t2 related to these methods?
- tedunangst 9y ago
  Sparc didn't get out of order until T4 unless I'm mistaken. (Assuming speculative execution was added about the same time.)
  - mzs 9y ago
    ldxa asi non-faulting load ultasparc-i circa '96
anonymfus 9y ago
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 https://lkml.org/lkml/2018/1/4/615
- puddums 9y ago
  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 https://lkml.org/lkml/2018/1/4/696
groom 9y ago
Are programs running on SmartOS zones vulnerable to any of the latest discoveries?
- loeg 9y ago
  Yes.
JdeBP 9y ago
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://news.ycombinator.com/item?id=16072009 * https://lkml.org/lkml/2018/1/4/432 https://lkml.org/lkml/2018/1/4/432 * https://news.ycombinator.com/item?id=16072775 https://news.ycombinator.com/item?id=16072775 * https://lkml.org/lkml/2018/1/4/615 https://lkml.org/lkml/2018/1/4/615 * https://news.ycombinator.com/item?id=16072806 https://news.ycombinator.com/item?id=16072806 * https://news.ycombinator.com/item?id=16075082 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://news.ycombinator.com/item?id=16076601 * https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5 https://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588 https://news.ycombinator.com/item?id=16075588)
- deleted 9y ago
  [deleted]
- bonzini 9y ago
  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).
  - 9y ago
deleted 9y ago
[deleted]

frik 9y ago

Does this mean Hyperthreading as we know it basically gets almost useless because of perf degeneration? Anyway it's shocking that all these things were possible, and Intel didn't care about security for 2 decades (since 1995).

mzs 9y ago

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

tedunangst 9y ago
Sparc didn't get out of order until T4 unless I'm mistaken. (Assuming speculative execution was added about the same time.)
- mzs 9y ago
  ldxa asi non-faulting load ultasparc-i circa '96

anonymfus 9y ago

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 https://lkml.org/lkml/2018/1/4/615

puddums 9y ago
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 https://lkml.org/lkml/2018/1/4/696

groom 9y ago

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

loeg 9y ago
Yes.

JdeBP 9y ago

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://news.ycombinator.com/item?id=16072009 * https://lkml.org/lkml/2018/1/4/432 https://lkml.org/lkml/2018/1/4/432 * https://news.ycombinator.com/item?id=16072775 https://news.ycombinator.com/item?id=16072775 * https://lkml.org/lkml/2018/1/4/615 https://lkml.org/lkml/2018/1/4/615 * https://news.ycombinator.com/item?id=16072806 https://news.ycombinator.com/item?id=16072806 * https://news.ycombinator.com/item?id=16075082 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://news.ycombinator.com/item?id=16076601 * https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5 https://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588 https://news.ycombinator.com/item?id=16075588)

deleted 9y ago
[deleted]
bonzini 9y ago
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).
- 9y ago

deleted 9y ago

[deleted]