Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Fri, 2018-01-05 at 17:09 -0800, Dan Williams wrote:
> Quoting Mark's original RFC:
> 
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [1]
> and the Documentation patch in this series."
> 
> This series incorporates Mark Rutland's latest api and adds the x86
> specific implementation of nospec_barrier. The
> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
> wide analysis performed by Elena Reshetova to address static analysis
> reports where speculative execution on a userspace controlled value
> could bypass a bounds check. The patches address a precondition for the
> attack discussed in the Spectre paper [2].
> 
> A consideration worth noting for reviewing these patches is to weigh the
> dramatic cost of being wrong about whether a given report is exploitable
> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
> lets make the bar for applying these patches be "can you prove that the
> bounds check bypass is *not* exploitable". Consider that the Spectre
> paper reports one example of a speculation window being ~180 cycles.
> 
> Note that there is also a proposal from Linus, array_access [3], that
> attempts to quash speculative execution past a bounds check without
> introducing an lfence instruction. That may be a future optimization
> possibility that is compatible with this api, but it would appear to
> need guarantees from the compiler that it is not clear the kernel can
> rely on at this point. It is also not clear that it would be a
> significant performance win vs lfence.

Thank you Dan for all the work you have done on this patch series. Before
I start reviewing the patches themselves I would like to know whether or
not the issue that is addressed by this patch series could also be addressed
by AMD and Intel by modifying the CPU microcode. And if this can be
addressed by modifying the CPU microcode, will accepting this patch series
reduce the pressure on CPU manufacturers to provide such an update?

Recently I learned that Intel released a microcode update on November 17th,
2017. Are there release notes available for that microcode update that
explain what changes are include in that specific and in previous microcode
updates? See also
https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

Thanks,

Bart.