historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1
Date: Thu, 12 Mar 2020 01:34:50 +0000	[thread overview]
Message-ID: <f9a612eb-6da5-23e9-e85e-f97fc67cda34@citrix.com> (raw)
In-Reply-To: <20200312002521.GA32316@agluck-desk2.amr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

On 12/03/2020 00:25, speck for Luck, Tony wrote:
> On Wed, Mar 11, 2020 at 04:18:19PM -0700, speck for mark gross wrote:
>> On Wed, Mar 11, 2020 at 08:28:36PM +0000, speck for Andrew Cooper wrote:
>>> On 16/01/2020 22:16, speck for mark gross wrote:
>>>> +static void __init srbds_select_mitigation(void)
>>>> +{
>>>> +	u64 ia32_cap;
>>>> +
>>>> +	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
>>>> +		srbds_mitigation = SRBDS_NOT_AFFECTED;
>>>> +		return;
>>>> +	}
>>>> +
>>>> +	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
>>>> +		srbds_mitigation = SRBDS_HYPERVISOR;
>>>> +		return;
>>>> +	}
>>> These two ought to be reversing (and with a suitable adjustment to the
>>> docs in patch 2).
>>>
>>> If you're running as a guest, you can't even trust the model number used
>>> to divine X86_BUG_SRBDS in the first place.
>>>
>> I'll change this for the next version.
> Andrew: Are you really sure that you want that?

I thought I was...

> It would
> mean that all guests running on any server level Xeon
> would report mitigation status as unknown. Actually
> all those server Xeons are not affected by SRBDS.

There are Xeon E3's to be found, in server form factors, in clouds.

> Technically that is entirely the right thing to do. But
> how much do hypervisors mess with the CPU model between
> different classes on processors in practice? I thought
> that commonly people put a bunch of Haswell/Broadwell/Skylakes
> into a "pool" and pretended they were all Haswell.

I actually made this point for KVM's benefit, which does (to the best of
my knowledge) behave like that.

With Xen, a VM sees the real F/M/S of the processor it first started on,
even if the reported features is way off from what a native version of
that CPU would look like.

I can't speak to other hypervisors, but it would be a reasonable
question to ask the keybase group.

> Do you want to consider the tradeoff between being
> absolutely accurate against all the support calls
> you will get because guests report "unknown" mitigation
> status?

vs the warm, fuzzy, and sinking feeling where it says safe, but isn't
actually?

Also, consider the case of a mix of E3's and E5's in a single migration
pool, which is disappointingly common at least at the enterprise level.

I accept this is a complicated problem, but personally, I view providing
potentially-wrong information worse than saying "ask the person who runs
your hypervisor".

Particularly with this issue where it seems that no hypervisor is
interested in offering the knob to guest kernels (so could at least
infer based on SRBDS_CTRL), nor is there an ARCH_CAPS_$FOO_NO bit which
could be filled in by a hypervisor on unaffected or mitigated hardware.

After all, the question of "are my random numbers known elsewhere?" also
depends on "is my hypervisor intercepting the RDRAND/RDSEED
instructions?" and possibly "has someone set the DETERMINISTIC_RNG bit
behind my back?".

~Andrew


  reply	other threads:[~2020-03-12  1:36 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
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 [this message]
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=f9a612eb-6da5-23e9-e85e-f97fc67cda34@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1' \
    /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).