linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Fuad Tabba <tabba@google.com>
To: Andrew Jones <drjones@redhat.com>
Cc: "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
	<kvmarm@lists.cs.columbia.edu>,
	kernel-team@android.com,  kvm@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>,
	pbonzini@redhat.com,  Will Deacon <will@kernel.org>,
	 "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v1 00/13] KVM: arm64: Fixed features for protected VMs
Date: Wed, 9 Jun 2021 16:22:55 +0100	[thread overview]
Message-ID: <CA+EHjTxuzSVVk-U20wpw5-JjhyXOFN1sCRv3AhAsd9yNeM8cEg@mail.gmail.com> (raw)
In-Reply-To: <20210608150739.7ztstw52ynxh6m5p@gator>

Hi Drew,

> I see this series takes the approach we currently have in KVM of masking
> features we don't want to expose to the guest. This approach adds yet
> another "reject list" to be maintained as hardware evolves. I'd rather see
> that we first change KVM to using an accept list, i.e. mask everything and
> then only set what we want to enable. Mimicking that new accept list in
> pKVM, where much less would be enabled, would reduce the amount of
> maintenance needed.

Good point. I agree that having an allow list is preferable to having
a block list. The way this patch series handles system register
accesses is actually an allow list. However, as it is now, features
being exposed to protected guests via the feature registers take the
block list approach. I will fix that to ensure that instead it exposes
a list of allowed features, rather than hiding restricted ones. As you
suggest, this would reduce the amount of maintenance as hardware
evolves and is better for security as well.

As for changing KVM first, I think that that's orthogonal to what this
series is trying to accomplish. Features in pKVM are not controlled or
negotiable by userspace, as it is a fixed virtual platform. When KVM
changes to use allow lists instead, it shouldn't conflict with how
this series works, especially if I fix it to use an allow list
instead.

Thanks for your feedback.

Cheers,
/fuad


> Thanks,
> drew
>
> >
> > This series is based on kvmarm/next and Will's patches for an Initial pKVM user
> > ABI [1]. You can find the applied series here [2].
> >
> > Cheers,
> > /fuad
> >
> > [1] https://lore.kernel.org/kvmarm/20210603183347.1695-1-will@kernel.org/
> >
> > For more details about pKVM, please refer to Will's talk at KVM Forum 2020:
> > https://www.youtube.com/watch?v=edqJSzsDRxk
> >
> > [2] https://android-kvm.googlesource.com/linux/+/refs/heads/tabba/el2_fixed_feature_v1
> >
> > To: kvmarm@lists.cs.columbia.edu
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: James Morse <james.morse@arm.com>
> > Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Christoffer Dall <christoffer.dall@arm.com>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Quentin Perret <qperret@google.com>
> > Cc: kvm@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: kernel-team@android.com
> >
> > Fuad Tabba (13):
> >   KVM: arm64: Remove trailing whitespace in comments
> >   KVM: arm64: MDCR_EL2 is a 64-bit register
> >   KVM: arm64: Fix name of HCR_TACR to match the spec
> >   KVM: arm64: Refactor sys_regs.h,c for nVHE reuse
> >   KVM: arm64: Restore mdcr_el2 from vcpu
> >   KVM: arm64: Add feature register flag definitions
> >   KVM: arm64: Add config register bit definitions
> >   KVM: arm64: Guest exit handlers for nVHE hyp
> >   KVM: arm64: Add trap handlers for protected VMs
> >   KVM: arm64: Move sanitized copies of CPU features
> >   KVM: arm64: Trap access to pVM restricted features
> >   KVM: arm64: Handle protected guests at 32 bits
> >   KVM: arm64: Check vcpu features at pVM creation
> >
> >  arch/arm64/include/asm/kvm_arm.h        |  34 +-
> >  arch/arm64/include/asm/kvm_asm.h        |   2 +-
> >  arch/arm64/include/asm/kvm_host.h       |   2 +-
> >  arch/arm64/include/asm/kvm_hyp.h        |   4 +
> >  arch/arm64/include/asm/sysreg.h         |   6 +
> >  arch/arm64/kvm/arm.c                    |   4 +
> >  arch/arm64/kvm/debug.c                  |   5 +-
> >  arch/arm64/kvm/hyp/include/hyp/switch.h |  42 ++
> >  arch/arm64/kvm/hyp/nvhe/Makefile        |   2 +-
> >  arch/arm64/kvm/hyp/nvhe/debug-sr.c      |   2 +-
> >  arch/arm64/kvm/hyp/nvhe/mem_protect.c   |   6 -
> >  arch/arm64/kvm/hyp/nvhe/switch.c        | 114 +++++-
> >  arch/arm64/kvm/hyp/nvhe/sys_regs.c      | 501 ++++++++++++++++++++++++
> >  arch/arm64/kvm/hyp/vhe/debug-sr.c       |   2 +-
> >  arch/arm64/kvm/pkvm.c                   |  31 ++
> >  arch/arm64/kvm/sys_regs.c               |  62 +--
> >  arch/arm64/kvm/sys_regs.h               |  35 ++
> >  17 files changed, 782 insertions(+), 72 deletions(-)
> >  create mode 100644 arch/arm64/kvm/hyp/nvhe/sys_regs.c
> >
> >
> > base-commit: 35b256a5eebe3ac715b4ea6234aa4236a10d1a88
> > --
> > 2.32.0.rc1.229.g3e70b5a671-goog
> >
> > _______________________________________________
> > kvmarm mailing list
> > kvmarm@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> >
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-09 16:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 14:11 [PATCH v1 00/13] KVM: arm64: Fixed features for protected VMs Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 01/13] KVM: arm64: Remove trailing whitespace in comments Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 02/13] KVM: arm64: MDCR_EL2 is a 64-bit register Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 03/13] KVM: arm64: Fix name of HCR_TACR to match the spec Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 04/13] KVM: arm64: Refactor sys_regs.h,c for nVHE reuse Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 05/13] KVM: arm64: Restore mdcr_el2 from vcpu Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 06/13] KVM: arm64: Add feature register flag definitions Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 07/13] KVM: arm64: Add config register bit definitions Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 08/13] KVM: arm64: Guest exit handlers for nVHE hyp Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 09/13] KVM: arm64: Add trap handlers for protected VMs Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 10/13] KVM: arm64: Move sanitized copies of CPU features Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 11/13] KVM: arm64: Trap access to pVM restricted features Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 12/13] KVM: arm64: Handle protected guests at 32 bits Fuad Tabba
2021-06-08 14:11 ` [PATCH v1 13/13] KVM: arm64: Check vcpu features at pVM creation Fuad Tabba
2021-06-08 15:07 ` [PATCH v1 00/13] KVM: arm64: Fixed features for protected VMs Andrew Jones
2021-06-09 15:22   ` Fuad Tabba [this message]
2021-06-11 12:44 ` Alexandru Elisei
2021-06-13 16:12   ` Fuad Tabba

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=CA+EHjTxuzSVVk-U20wpw5-JjhyXOFN1sCRv3AhAsd9yNeM8cEg@mail.gmail.com \
    --to=tabba@google.com \
    --cc=drjones@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.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).