Re: [PATCH 2/2] v3 more sampling fun 2

Mark,

speck for mark gross <[email protected]> writes:
> On Wed, Mar 11, 2020 at 09:26:18PM +0100, speck for Thomas Gleixner wrote:
>> speck for mark gross <[email protected]> writes:
>> > +  =============  ============  ========
>> > +  common name    Family_Model  Stepping
>> > +  =============  ============  ========
>> > +  Ivybridge      06_3AH        All
>> > +
>> > +  Haswell        06_3CH        All
>> > +  Haswell_L      06_45H        All
>> > +  Haswell_G      06_46H        All
>> > +
>> > +  Broadwell_G    06_47H        All
>> > +  Broadwell      06_3DH        All
>> > +
>> > +  Skylake_L      06_4EH        All
>> > +  Skylake        06_5EH        All
>> > +
>> > +  Kabylake_L     06_8EH        <=A
>> > +  Kabylake_L     06_8EH        0xB only if TSX is enabled
>> > +  Kabylake_L     06_8EH        0xC only if TSX is enabled
>> > +
>> > +  Kabylake       06_9EH        <=B
>> > +  Kabylake       06_9EH        0xC only if TSX is enabled
>> > +  Kabylake       06_9EH        0xD only if TSX is enabled
>> > +  =============  ============  ========
>> 
>> > +  =============  ============  ===========================
>> 
>> ditto at the top of the table.
> I don't understand this feedback.

The length of '===' must be at least as long as the text in the rows. At
least that was a requirement in the past. Maybe it got relaxed, but even
then it looks more consistent:

  =============  ============  ========
  Kabylake       06_9EH        0xD only if TSX is enabled
  =============  ============  ========

vs.

  =============  ============  ===========================
  Kabylake       06_9EH        0xD only if TSX is enabled
  =============  ============  ===========================

>> > +Attack scenarios
>> > +---------------
>> > +An unprivileged user can extract returned values from RDRAND and RDSEED
>> > +executed on another core or sibling thread using MDS techniques.
>> 
>> Lacks EGETKEY again.
> no, egetkey is not an instruction for use outside an SGX enclave.
>
> Also, the mitigation only alows MSR control of the mitigation for RDRAND and
> RDSEED.  EGETKEY is always mitigated.

This is talking about attack scenarios not about mitigations.

>> > +Default mitigations
>> > +-------------------
>> > +This new microcode serializes processor access during execution of RDRAND,
>> > +RDSEED ensures that the shared buffer is overwritten before it is released for
>> > +reuse.
>> 
>> Errm. What has this to do with the default chosen by the kernel?
> its a statement that if the kernel does nothing then the mitigation is in
> effect.

Then please write it in a way which makes it clear what the kernel does
by default.

  If updated microcode is available, the microcode mitigation which
  overwrites the shared buffer is enabled by default.

Or something to that effect.

Thanks,

        tglx