From: Sean Christopherson <seanjc@google.com>
To: Reiji Watanabe <reijiw@google.com>
Cc: Raghavendra Rao Ananta <rananta@google.com>,
kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Peter Shier <pshier@google.com>,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Jim Mattson <jmattson@google.com>
Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start
Date: Wed, 19 Jan 2022 00:07:44 +0000 [thread overview]
Message-ID: <YedWUJNnQK3HFrWC@google.com> (raw)
In-Reply-To: <CAAeT=Fz2q4PfJMXes3A9f+c01NnyORbvUrzJZO=ew-LsjPq2jQ@mail.gmail.com>
On Fri, Jan 14, 2022, Reiji Watanabe wrote:
> The restriction, with which KVM doesn't need to worry about the changes
> in the registers after KVM_RUN, could potentially protect or be useful
> to protect KVM and simplify future changes/maintenance of the KVM codes
> that consumes the values.
That sort of protection is definitely welcome, the previously mentioned CPUID mess
on x86 would have benefit greatly by KVM being restrictive in the past. That said,
hooking KVM_RUN is likely the wrong way to go about implementing any restrictions.
Running a vCPU is where much of the vCPU's state is explicitly consumed, but it's
all too easy for KVM to implicity/indirectly consume state via a different ioctl(),
e.g. if there are side effects that are visible in other registers, than an update
can also be visible to userspace via KVM_{G,S}ET_{S,}REGS, at which point disallowing
modifying state after KVM_RUN but not after reading/writing regs is arbitrary and
inconsitent.
If possible, preventing modification if kvm->created_vcpus > 0 is ideal as it's
a relatively common pattern in KVM, and provides a clear boundary to userpace
regarding what is/isn't allowed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-19 0:09 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 19:49 [RFC PATCH v3 00/11] KVM: arm64: Add support for hypercall services selection Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 01/11] KVM: Capture VM start Raghavendra Rao Ananta
2022-01-07 6:06 ` Reiji Watanabe
2022-01-07 23:43 ` Raghavendra Rao Ananta
2022-01-08 0:04 ` Jim Mattson
2022-01-10 23:07 ` Raghavendra Rao Ananta
2022-01-10 23:57 ` Jim Mattson
2022-01-11 18:52 ` Raghavendra Rao Ananta
2022-01-11 19:16 ` Jim Mattson
2022-01-12 18:29 ` Raghavendra Rao Ananta
2022-01-13 17:21 ` Sean Christopherson
2022-01-14 0:42 ` Raghavendra Rao Ananta
2022-01-14 1:10 ` Sean Christopherson
2022-01-14 21:51 ` Reiji Watanabe
2022-01-18 22:54 ` Raghavendra Rao Ananta
2022-01-19 0:07 ` Sean Christopherson [this message]
2022-01-19 7:47 ` Reiji Watanabe
2022-01-20 0:27 ` Sean Christopherson
2022-01-20 19:16 ` Raghavendra Rao Ananta
2022-01-25 15:15 ` Marc Zyngier
2022-01-25 15:10 ` Marc Zyngier
2022-01-11 0:03 ` Reiji Watanabe
2022-01-11 18:54 ` Raghavendra Rao Ananta
2022-01-08 1:06 ` Sean Christopherson
2022-01-10 23:23 ` Raghavendra Rao Ananta
2022-01-11 17:36 ` Sean Christopherson
2022-01-11 18:46 ` Raghavendra Rao Ananta
2022-01-11 19:04 ` Sean Christopherson
2022-01-12 18:08 ` Raghavendra Rao Ananta
2022-01-12 18:24 ` Sean Christopherson
2022-01-12 18:31 ` Sean Christopherson
2022-01-04 19:49 ` [RFC PATCH v3 02/11] KVM: arm64: Factor out firmware register handling from psci.c Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP Raghavendra Rao Ananta
2022-01-08 5:40 ` Reiji Watanabe
2022-01-10 23:40 ` Raghavendra Rao Ananta
2022-01-11 4:33 ` Reiji Watanabe
2022-01-04 19:49 ` [RFC PATCH v3 04/11] KVM: arm64: Setup a framework for hypercall bitmap firmware registers Raghavendra Rao Ananta
2022-01-10 6:28 ` Reiji Watanabe
2022-01-11 0:50 ` Raghavendra Rao Ananta
2022-01-12 5:11 ` Reiji Watanabe
2022-01-12 18:02 ` Raghavendra Rao Ananta
2022-01-14 6:23 ` Reiji Watanabe
2022-01-19 6:42 ` Jason Wang
2022-01-19 10:21 ` Marc Zyngier
2022-01-04 19:49 ` [RFC PATCH v3 05/11] KVM: arm64: Add standard hypervisor firmware register Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 06/11] KVM: arm64: Add vendor " Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 07/11] Docs: KVM: Add doc for the bitmap firmware registers Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 08/11] Docs: KVM: Rename psci.rst to hypercalls.rst Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 09/11] tools: Import ARM SMCCC definitions Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 10/11] selftests: KVM: aarch64: Introduce hypercall ABI test Raghavendra Rao Ananta
2022-01-04 19:49 ` [RFC PATCH v3 11/11] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list Raghavendra Rao Ananta
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=YedWUJNnQK3HFrWC@google.com \
--to=seanjc@google.com \
--cc=catalin.marinas@arm.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=will@kernel.org \
/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 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).