From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH 6/7] KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional
Date: Thu, 14 Jan 2021 09:34:50 -0800 [thread overview]
Message-ID: <YACAunykMZWrbMwm@google.com> (raw)
In-Reply-To: <87v9bz7sdk.fsf@vitty.brq.redhat.com>
On Thu, Jan 14, 2021, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
>
> > On Wed, Jan 13, 2021, Vitaly Kuznetsov wrote:
> >> 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
> >
> > Would adding a module param buy us anything (other than complexity)?
> >
>
> A tiny bit, yes. This series is aimed at protecting KVM from 'curious
> guests' which can try to enable Hyper-V emulation features even when
> they don't show up in CPUID. A module parameter would help to protect
> against a malicious VMM which can still enable all these features. What
> I'm not sure about is how common Linux-guests-only deployments (where
> the parameter can actually get used) are as we'll have to keep it
> 'enabled' by default to avoid breaking existing deployments.
I always forget that these "optional" features aren't so optional for Windows
guests. Given that, it does seem like a module param would be of dubious value.
What I really want for my own personal development is a Kconfig option to turn
it off completely and shave a few cycles of build time, but I can't even justify
that to myself :-)
next prev parent reply other threads:[~2021-01-14 17:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 14:37 [PATCH 0/7] KVM: x86: Conditional Hyper-V emulation enablement Vitaly Kuznetsov
2021-01-13 14:37 ` [PATCH 1/7] selftests: kvm: Move kvm_get_supported_hv_cpuid() to common code Vitaly Kuznetsov
2021-01-13 14:37 ` [PATCH 2/7] selftests: kvm: Properly set Hyper-V CPUIDs in evmcs_test Vitaly Kuznetsov
2021-01-13 14:37 ` [PATCH 3/7] KVM: x86: hyper-v: Always use vcpu_to_hv_vcpu() accessor to get to 'struct kvm_vcpu_hv' Vitaly Kuznetsov
2021-01-19 23:05 ` Sean Christopherson
2021-01-20 12:15 ` Vitaly Kuznetsov
2021-01-20 17:55 ` Sean Christopherson
2021-01-13 14:37 ` [PATCH 4/7] KVM: x86: hyper-v: Prepare to meet unallocated Hyper-V context Vitaly Kuznetsov
2021-01-13 14:37 ` [PATCH 5/7] KVM: x86: hyper-v: Allocate 'struct kvm_vcpu_hv' dynamically Vitaly Kuznetsov
2021-01-13 14:37 ` [PATCH 6/7] KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional Vitaly Kuznetsov
2021-01-13 20:49 ` Sean Christopherson
2021-01-14 9:57 ` Vitaly Kuznetsov
2021-01-14 17:34 ` Sean Christopherson [this message]
2021-01-13 14:37 ` [PATCH 7/7] KVM: x86: hyper-v: Allocate Hyper-V context lazily Vitaly Kuznetsov
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=YACAunykMZWrbMwm@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.