historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mark gross <mgross@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 2/2] v3 more sampling fun 2
Date: Thu, 12 Mar 2020 15:04:18 -0700	[thread overview]
Message-ID: <20200312220418.GA106528@mtg-dev.jf.intel.com> (raw)
In-Reply-To: <87r1xyk591.fsf@nanos.tec.linutronix.de>

On Wed, Mar 11, 2020 at 09:26:18PM +0100, speck for Thomas Gleixner wrote:
> speck for mark gross <speck@linutronix.de> writes:
> > diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
> > new file mode 100644
> > index 000000000000..5acc7748f8e9
> > --- /dev/null
> > +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
> > @@ -0,0 +1,145 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +SRBDS - Special Register Buffer Data Sampling
> > +======================================
> 
> I doubt that this builds w/o warnings. And right:

It does now.

> 
> Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:4: WARNING: Title underline too short.
> 
> SRBDS - Special Register Buffer Data Sampling
> ======================================^
fixed.
> 
> Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:56: WARNING: Title underline too short.
> 
> Attack scenarios
> ---------------^
fixed.
> 
> Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:76: WARNING: Unexpected indentation.
> Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:77: WARNING: Block quote ends without a blank line; unexpected unindent.
fixed.
> 
> Sigh...
> 
> > +SRBDS is a hardware vulnerability that allows MDS techniques to infer values
> 
> lacks a link to the MDS documentation

will fix.

> 
> > +returned from special register accesses.  Special register accesses are
> > +accesses to off core registers.  According to Intels evaluation, the special
> > +register reads that have a security expectation of privacy are:
> > +RDRAND, RDSEED and SGX EGETKEY.
> 
> And what 
> 
> > +
> > +When RDRAND and RDSEED instructions are used the data is moved to the core
> > +through the special register mechanism.
> 
> This sentence is not providing any new information and can be packed in
> the above where you mention RDRAND, RDSEED already. EGETKEY is no instruction?
added " that is susceptible to MDS attacks."

> 
> > +Affected processors
> > +--------------------
> > +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED and
> > +are vulnerable to MFBDS (Micro architectural Fill Buffer Data
> > Sampling) variant
> 
> s/to/to the/
done.

> 
> > +of MDS (Micro architectural Data Sampling) or to TAA (TSX Asynchronous Abort)
> > +when TSX is enabled,
> > +
> > +  =============  ============  ========
> > +  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.


> 
> > +
> > +Related CVEs
> > +------------
> > +
> > +The following CVE entry is related to this SRBDS issue:
> > +
> > +    ==============  =====  ===================================================
> > +    CVE-2020--0543
> > +    ==============  =====  ===================================================
> 
> Is the void filled at some point?
Working on it.

> 
> > +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.

> 
> > +
> > +
> > +Mitigtion mechanism
> > +-------------------
> > +Intel will release microcode updates that modify the RDRAND, RDSEED, and
> > +EGETKEY instructions to overwrite secret special register data in the shared
> > +staging buffer before the secret data can be accessed by another logical
> > +processor.
> > +
> > +During execution of the RDRAND, RDSEED, or EGETKEY instruction, off-core
> > +accesses from other logical processors will be delayed until the special
> > +register read is complete and the secret data in the shared staging buffer is
> > +overwritten.
> > +
> > +This has three effects on performance:
> > +1 RDRAND, RDSEED, or EGETKEY instruction have higher latency.
> > +2 Executing RDRAND at the same time on multiple logical processors will be
> > +  serialized, resulting in an overall reduction in the maximum RDRAND bandwidth.
> > +3 Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other
> > +  logical processors that miss their core caches, with an impact similar to
> > +  legacy locked cache-line-split accesses.
> 
> I seriously doubt that you ever looked at the build output of this.
I can see why you doubt I ever looked at the output.  FWIW I used gitlab to
view the *.rst formatting and I was focused on fighting the table below to the
point I missed this section.

this list is fixed now.


> > +
> > +Because of the performance impact of the mitigation, the microcode updates also
> > +provide an opt-out mechanism (RNGDS_MITG_DIS) to disable the mitigation for
> > +RDRAND and RDSEED instructions executed outside of Intel Software Guard
> > +Extensions (Intel SGX) enclaves. On logical processors that disable the
> > +mitigation using this opt-out mechanism, RDRAND and RDSEED do not take longer
> > +to execute and do not impact performance of sibling logical processors memory
> > +accesses. The opt-out mechanism does not affect Intel SGX enclaves (including
> > +execution of RDRAND or RDSEED inside of an enclave, as well as EGETKEY
> > +execution).
> > +
> > +IA32_MCU_OPT_CTRL MSR Definition
> > +--------------------------------
> > +Along with the mitigation for this issue, Intel added a new thread-scope
> > +IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
> > +RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
> > +9]==1. This MSR is introduced through the microcode update.
> > +
> > +Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
> > +disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
> > +enclave on that logical processor. Opting out of the mitigation for a
> > +particular logical processor does not affect the RDRAND and RDSEED mitigations
> > +for other logical processors.
> > +
> > +Note that inside of an Intel SGX enclave, the mitigation is applied regardless
> > +of the value of RNGDS_MITG_DS.
> > +
> > +Mitigation control on the kernel command line
> > +---------------------------------------------
> > +The kernel command line allows for control over the SRBDS mitigation
> > at boot
> 
> allows control (methinks)
ok.

> 
> > +time with the option "srbds=".  The option for this is:
> > +
> > +  ============= ============================================================
> > +  off           This option disables SRBS mitigation for RDRAND and RDSEED on
> > +                affected platforms.
> > +  ============= ============================================================
> > +
> > +SRBS System Information
> > +-----------------------
> > +The Linux kernel provides vulnerability status information through sysfs.  For
> > +SRBDS this can be accessed by the following sysfs file:
> > +/sys/devices/system/cpu/vulnerabilities/special_register_data_sampling
> > +
> > +The possible values contained in this file are:
> > +
> > + ============================== ===========================================
> > + Not affected                   Processor not vulnerable
> > + Vulnerable                     Processor vulnerable and mitigation disabled
> > + Vulnerable: no microcode       Processor vulnerable and microcode is missing
> > +                                mitigation
> > + Mitigated                      Processor is vulnerable and mitigation is in
> > +                                effect.
> > + Not affected (TSX disabled)    Processor is only vulnerable when TSX is
> > +                                enabled while this system was booted with TSX
> > +                                disabled.
> > + Unknown                        Running on virtual guest processor that is
> > +                                affected but with no way to know if host
> > +                                processor is mitigated or vulnerable.
> > + ============================== ===========================================
> > +
> > +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.


thanks for the feedback.  Please respond about the comment I didn't understand.

--mark

  parent reply	other threads:[~2020-03-12 22:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 15:39 [MODERATED] [PATCH 0/2] v3 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 1/2] v3 more sampling fun 1 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 2/2] v3 more sampling fun 2 mark gross
     [not found] ` <5e690bea.1c69fb81.16d6d.4b78SMTPIN_ADDED_BROKEN@mx.google.com>
2020-03-11 17:21   ` [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1 Greg KH
2020-03-11 23:09     ` mark gross
2020-03-11 20:02 ` Thomas Gleixner
2020-03-17 18:56   ` [MODERATED] " mark gross
2020-03-11 20:26 ` [PATCH 2/2] v3 more sampling fun 2 Thomas Gleixner
2020-03-11 20:38   ` [MODERATED] " Andrew Cooper
2020-03-11 23:23   ` mark gross
2020-03-12 22:04   ` mark gross [this message]
2020-03-13 15:21     ` Thomas Gleixner
2020-03-11 20:28 ` [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1 Andrew Cooper
2020-03-11 23:18   ` mark gross
2020-03-12  0:25     ` Luck, Tony
2020-03-12  1:34       ` Andrew Cooper
2020-03-12 15:25         ` Luck, Tony
2020-03-12 16:02           ` Luck, Tony
2020-03-12 16:45             ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200312220418.GA106528@mtg-dev.jf.intel.com \
    --to=mgross@linux.intel.com \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] Re: [PATCH 2/2] v3 more sampling fun 2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).