From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: [PATCH 2/2] v3 more sampling fun 2
Date: Fri, 13 Mar 2020 16:21:00 +0100 [thread overview]
Message-ID: <875zf8i8mb.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200312220418.GA106528@mtg-dev.jf.intel.com>
Mark,
speck for mark gross <speck@linutronix.de> writes:
> On Wed, Mar 11, 2020 at 09:26:18PM +0100, speck for Thomas Gleixner wrote:
>> speck for mark gross <speck@linutronix.de> 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
next prev parent reply other threads:[~2020-03-13 15:21 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
2020-03-13 15:21 ` Thomas Gleixner [this message]
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=875zf8i8mb.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=speck@linutronix.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).