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

[Andrew Cooper <andrew.cooper3@citrix.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