Re: Detecting whether dom0 is in a VM

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.07.2023 12:16, Jan Beulich wrote:
> On 07.07.2023 11:52, George Dunlap wrote:
>> On Fri, Jul 7, 2023 at 9:00 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>>> On 06.07.2023 17:35, zithro wrote:
>>>> On 06 Jul 2023 09:02, Jan Beulich wrote:
>>>>> On 05.07.2023 18:20, zithro wrote:
>>>>>> So I'm wondering, isn't that path enough for correct detection ?
>>>>>> I mean, if "/sys/class/dmi/id/sys_vendor" reports Xen (or KVM, or any
>>>>>> other known hypervisor), it's nested, otherwise it's on hardware ?
>>>>>>
>>>>>> Is that really mandatory to use CPUID leaves ?
>>>>>
>>>>> Let me ask the other way around: In user mode code under a non-nested
>>>>> vs nested Xen, what would you be able to derive from CPUID? The
>>>>> "hypervisor" bit is going to be set in both cases. (All assuming you
>>>>> run on new enough hardware+Xen such that CPUID would be intercepted
>>>>> even for PV.)
>>>>
>>>> I'm a bit clueless about CPUID stuff, but if I understand correctly,
>>>> you're essentially saying that using CPUID may not be the perfect way ?
>>>> Also, I don't get why the cpuid command returns two different values,
>>>> depending on the -k switch :
>>>> # cpuid -l 0x40000000
>>>> hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0"
>>>> # cpuid -k -l 0x40000000
>>>> hypervisor_id (0x40000000) = "XenVMMXenVMM"
>>>
>>> I'm afraid I can't comment on this without knowing what tool you're
>>> taking about. Neither of the two systems I checked have one of this
>>> name.
>>>
>>>>> Yet relying on DMI is fragile, too: Along the lines of
>>>>> https://lists.xen.org/archives/html/xen-devel/2022-01/msg00604.html
>>>>> basically any value in there could be "inherited" from the host (i.e.
>>>>> from the layer below, to be precise).
>>>>
>>>> So using "/sys/class/dmi/id/sys_vendor", or simply doing "dmesg | grep
>>>> DMI:" is also not perfect, as values can be inherited/spoofed by
>>>> underneath hypervisor ?
>>>
>>> That's my understanding, yes.
>>>
>>>>> The only way to be reasonably
>>>>> certain is to ask Xen about its view. The raw or host featuresets
>>>>> should give you this information, in the "mirror" of said respective
>>>>> CPUID leave's "hypervisor" bit.
>>>>
>>>> As said above, I'm clueless, can you expand please ?
>>>
>>> Xen's public interface offers access to the featuresets known / found /
>>> used by the hypervisor. See XEN_SYSCTL_get_cpu_featureset, accessible
>>> via xc_get_cpu_featureset().
>>>
>>
>> Are any of these exposed in dom0 via sysctl, or hypfs?
> 
> sysctl - yes (as the quoted name also says). hypfs no, afaict.
> 
>>  SYSCTLs are
>> unfortunately not stable interfaces, correct?  So it wouldn't be practical
>> for systemd to use them.
> 
> Indeed, neither sysctl-s nor the libxc interfaces are stable.

Thinking of it, xen-cpuid is a wrapper tool around those. They may want
to look at its output (and, if they want to use it, advise distros to
also package it), which I think we try to keep reasonably stable,
albeit without providing any guarantees.

Jan