diff options
author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2021-01-26 14:48:14 +0100 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-02-09 08:39:56 -0500 |
commit | 8f014550dfb114cc7f42a517d20d2cf887a0b771 (patch) | |
tree | b18a8f8c96c597d215d831207472d07508e1395b /fs/open.c | |
parent | 4592b7eaa87d3525825d4ab2a35308bcec9e5ff9 (diff) | |
download | linux-8f014550dfb114cc7f42a517d20d2cf887a0b771.tar.gz linux-8f014550dfb114cc7f42a517d20d2cf887a0b771.tar.bz2 linux-8f014550dfb114cc7f42a517d20d2cf887a0b771.zip |
KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional
Hyper-V emulation is enabled in KVM unconditionally. This is bad at least
from security standpoint as it is an extra attack surface. Ideally, there
should be a per-VM capability explicitly enabled by VMM but currently it
is not the case and we can't mandate one without breaking backwards
compatibility. We can, however, check guest visible CPUIDs and only enable
Hyper-V emulation when "Hv#1" interface was exposed in
HYPERV_CPUID_INTERFACE.
Note, VMMs are free to act in any sequence they like, e.g. they can try
to set MSRs first and CPUIDs later so we still need to allow the host
to read/write Hyper-V specific MSRs unconditionally.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210126134816.1880136-14-vkuznets@redhat.com>
[Add selftest vcpu_set_hv_cpuid API to avoid breaking xen_vmcall_test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'fs/open.c')
0 files changed, 0 insertions, 0 deletions