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://medium.com/@frankycaron/this-week-in-words-the-langu... (https://news.ycombinator.com/item?id=16075588)
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).
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. (-:
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.
Given a class-action was filed after the Project Zero reveal , I suspect Intel's lawyers are doing everything they can to avoid any indication there is a defect in their chips.
In addition, functional specifications are sometimes modified to conform to as-built behavior. When used responsibly, this is a reasonable response, and in practice unavoidable for something as complex as a modern processor.
On the other hand, Intel's statements are silent about what implications cannot be found in the effort they and others are putting into mitigating this feature.
Tangentially, the Titanic sailed with the number of lifeboats it was designed to carry.
"For Intel® Core™ processors of the Broadwell generation and later, this retpoline mitigation strategy also requires a microcode update to be applied for the mitigation to be fully effective."
vs. at least what I had seen on LKML list yesterday seemed to indicate Skylake+.
Sample snippet from LKML:
"The x86 IBRS feature requires corresponding microcode support.
It mitigates the variant 2 vulnerability..."
and related sample snippet from LKML:
"On Skylake the target for a 'ret' instruction may also come from the
BTB. So if you ever let the RSB (which remembers where the 'call's came
from get empty, you end up vulnerable.
Other than the obvious call stack of more than 16 calls in depth,
there's also a big list of other things which can empty the RSB,
including an SMI.
Which basically makes retpoline on Skylake+ very hard to use
reliably. The plan is to use IBRS there and not retpoline."
I'll confess I'm not 100% following all the ins and outs of this, but can anyone comment on any additional details regarding the Skylake+ vs. Broadwell+, and/or confirm if there was seemingly a change?
They are releasing microcode update mitigations for the CPUs of today, and at least state they will be improving things in the CPUs of the future, which is more-or-less what one might guess they would do with billions of dollars at stake.
That's not to say that they are going to magically get rid of all speculative execution, and I wouldn't try defending their PR approach, but one would guess they would at a bare minimum whittle away at the cost of mitigations.
Some related snippets about at least declared future intent. This obviously isn't a comprehensive list, but I think it suggests they realize the current state of affairs is not good for them:
From LKML related to approach taken with the new microcode update for variant #2 being better/less costly in future CPUs:
Later CPUs are intended to have an 'IBRS all the time' feature which is
set-and-forget, and will perform much better, I believe. If we find
we're running on a CPU with that, we'll turn off the retpoline..."
And from today's Intel PDF regarding variant #2:
There are three new capabilities that will now be supported for this mitigation strategy.
These capabilities will be available on modern existing products if the appropriate microcode update is
applied, as well as on future products, where the performance cost of these mitigations will be
And from today's Intel PDF regarding variant #3:
Future Intel processors will also have hardware support for mitigating Rogue Data Cache Load.
And a related comment from the always reputable source of "some security guy on the internet":
Whatever mitigations CPU vendors come up with will be in concert with software changes. "Page table isolation" is an overnight redesign of all operating systems. It's here to stay. The next step is for Intel CPUs to fix its performance cost
>"An attacker discovers or causes the creation of ‘confused deputy’ code which allows the attacker to cause speculative operations to reveal information not normally accessible to the attacker."
Can someone say what ‘confused deputy’ code means here? This is not a term I have ever come across before.
The authors then go on to state:
>"If the attacker can identify an appropriate ‘confused deputy’ in a more privileged level, the attackermay be able to exploit that deputy in order to deduce the contents of memory accessible to that deputy but not to the attacker."
Here the reference is to an "appropriate 'confused deputy.' Are these just weasel words? Can someone shed some light on "confused deputies" and what makes one "appropriate"?
That said, I don't think it's good label for what's going on.
a) a super-smart compiler that can anticipate lots of flaws and fence them or turn on restrictive modes (maybe V8 is this smart?)
b) you have to turn off more speculation than you wanted to, and it hits performance
SMAP looks cool, seems like same origin policy for pages, but this is more Meltdown than Spectre right?
(Also probably you can patch V8 interpreter to mitigate this issue, but this is a different story)
KeePass uses HTTP, and by the time it sees the request, it cannot do much if it's valid.
Part of me is outraged that Intel thinks it gets to have an opinion on the issue at all, after the absolutely chicken shit press release they issued.
the really tragic tale is that more businesses arent running AMD. Dan Luu sounded the alarm well before Meltdown, but people buy brands, not technology.