mbox series

[v3,00/15] KVM: SEV: allow customizing VMSA features

Message ID 20240226190344.787149-1-pbonzini@redhat.com (mailing list archive)
Headers show
Series KVM: SEV: allow customizing VMSA features | expand

Message

Paolo Bonzini Feb. 26, 2024, 7:03 p.m. UTC 
The idea that no parameter would ever be necessary when enabling SEV or
SEV-ES for a VM was decidedly optimistic.  The first source of variability
that was encountered is the desired set of VMSA features, as that affects
the measurement of the VM's initial state and cannot be changed
arbitrarily by the hypervisor.

This series adds all the APIs that are needed to customize the features,
with room for future enhancements:

- a new /dev/kvm device attribute to retrieve the set of supported
  features (right now, only debug swap)

- a new sub-operation for KVM_MEM_ENCRYPT_OP that can take a struct,
  replacing the existing KVM_SEV_INIT and KVM_SEV_ES_INIT

It then puts the new op to work by including the VMSA features as a field
of the The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of
supported VMSA features for backwards compatibility; but I am considering
also making them use zero as the feature mask, and will gladly adjust the
patches if so requested.

In order to avoid creating *two* new KVM_MEM_ENCRYPT_OPs, I decided that
I could as well make SEV and SEV-ES use VM types.  And then, why not make
a SEV-ES VM, when created with the new VM type instead of KVM_SEV_ES_INIT,
reject KVM_GET_REGS/KVM_SET_REGS and friends on the vCPU file descriptor
once the VMSA has been encrypted...  Which is how the API should have
always behaved.

The series is structured as follows:

- patches 1 to 5 are unrelated fixes and improvements for the SEV code
  and documentation.  In particular they change sev.c so that it is
  compiled only if SEV is enabled in kconfig

- patches 6 to 8 introduce the new device attribute to retrieve supported
  VMSA features

- patch 9 disables DEBUG_SWAP by default

- patches 10 and 11 introduce new infrastructure for VM types, replacing
  the similar code in the TDX patches

- patches 12 to 14 introduce the new VM types for SEV and
  SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP.

- patch 15 tests the new ioctl.

The idea is that SEV SNP will only ever support KVM_SEV_INIT2.  I have
patches in progress for QEMU to support this new API.

Thanks,

Paolo


v2->v3:
- use u64_to_user_addr()
- Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y
- remove double signoffs
- rebase on top of kvm-x86/next
- no bit masking hacks; store CoCo features in kvm_arch
- store supported VM types in kvm_caps
- introduce to_kvm_sev_info
- clearer output messages for failed assertions
- remove broken test

Paolo Bonzini (14):
  KVM: SEV: fix compat ABI for KVM_MEMORY_ENCRYPT_OP
  KVM: x86: use u64_to_user_addr()
  KVM: SVM: Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y
  Documentation: kvm/sev: separate description of firmware
  KVM: introduce new vendor op for KVM_GET_DEVICE_ATTR
  KVM: SEV: publish supported VMSA features
  KVM: SEV: store VMSA features in kvm_sev_info
  KVM: SEV: disable DEBUG_SWAP by default
  KVM: x86: add fields to struct kvm_arch for CoCo features
  KVM: x86: Add supported_vm_types to kvm_caps
  KVM: SEV: introduce to_kvm_sev_info
  KVM: SEV: define VM types for SEV and SEV-ES
  KVM: SEV: introduce KVM_SEV_INIT2 operation
  selftests: kvm: add tests for KVM_SEV_INIT2

Sean Christopherson (1):
  KVM: SVM: Invert handling of SEV and SEV_ES feature flags

 Documentation/virt/kvm/api.rst                |   2 +
 .../virt/kvm/x86/amd-memory-encryption.rst    |  81 ++++++--
 arch/x86/include/asm/kvm-x86-ops.h            |   1 +
 arch/x86/include/asm/kvm_host.h               |   8 +-
 arch/x86/include/uapi/asm/kvm.h               |  35 ++++
 arch/x86/kvm/Makefile                         |   7 +-
 arch/x86/kvm/cpuid.c                          |   2 +-
 arch/x86/kvm/svm/sev.c                        | 133 +++++++++----
 arch/x86/kvm/svm/svm.c                        |  15 +-
 arch/x86/kvm/svm/svm.h                        |  37 +++-
 arch/x86/kvm/x86.c                            | 174 ++++++++++++------
 arch/x86/kvm/x86.h                            |   2 +
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../selftests/kvm/include/kvm_util_base.h     |   6 +-
 .../selftests/kvm/set_memory_region_test.c    |   8 +-
 .../selftests/kvm/x86_64/sev_init2_tests.c    | 149 +++++++++++++++
 16 files changed, 527 insertions(+), 134 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86_64/sev_init2_tests.c

Comments

Bagas Sanjaya Feb. 27, 2024, 3:50 a.m. UTC | #1 
On Mon, Feb 26, 2024 at 02:03:29PM -0500, Paolo Bonzini wrote:
> The idea that no parameter would ever be necessary when enabling SEV or
> SEV-ES for a VM was decidedly optimistic.  The first source of variability
> that was encountered is the desired set of VMSA features, as that affects
> the measurement of the VM's initial state and cannot be changed
> arbitrarily by the hypervisor.
> 
> This series adds all the APIs that are needed to customize the features,
> with room for future enhancements:
> 
> - a new /dev/kvm device attribute to retrieve the set of supported
>   features (right now, only debug swap)
> 
> - a new sub-operation for KVM_MEM_ENCRYPT_OP that can take a struct,
>   replacing the existing KVM_SEV_INIT and KVM_SEV_ES_INIT
> 
> It then puts the new op to work by including the VMSA features as a field
> of the The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of
> supported VMSA features for backwards compatibility; but I am considering
> also making them use zero as the feature mask, and will gladly adjust the
> patches if so requested.
> 
> In order to avoid creating *two* new KVM_MEM_ENCRYPT_OPs, I decided that
> I could as well make SEV and SEV-ES use VM types.  And then, why not make
> a SEV-ES VM, when created with the new VM type instead of KVM_SEV_ES_INIT,
> reject KVM_GET_REGS/KVM_SET_REGS and friends on the vCPU file descriptor
> once the VMSA has been encrypted...  Which is how the API should have
> always behaved.
> 
> The series is structured as follows:
> 
> - patches 1 to 5 are unrelated fixes and improvements for the SEV code
>   and documentation.  In particular they change sev.c so that it is
>   compiled only if SEV is enabled in kconfig
> 
> - patches 6 to 8 introduce the new device attribute to retrieve supported
>   VMSA features
> 
> - patch 9 disables DEBUG_SWAP by default
> 
> - patches 10 and 11 introduce new infrastructure for VM types, replacing
>   the similar code in the TDX patches
> 
> - patches 12 to 14 introduce the new VM types for SEV and
>   SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP.
> 
> - patch 15 tests the new ioctl.
> 
> The idea is that SEV SNP will only ever support KVM_SEV_INIT2.  I have
> patches in progress for QEMU to support this new API.
> 
> Thanks,
> 
> Paolo
> 
> 
> v2->v3:
> - use u64_to_user_addr()
> - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y
> - remove double signoffs
> - rebase on top of kvm-x86/next

I can't apply this series on top of current kvm-x86/next. On what exact
commit the series is based on?

Confused...
Sean Christopherson Feb. 27, 2024, 5:49 p.m. UTC | #2 
On Tue, Feb 27, 2024, Bagas Sanjaya wrote:
> On Mon, Feb 26, 2024 at 02:03:29PM -0500, Paolo Bonzini wrote:
> > v2->v3:
> > - use u64_to_user_addr()
> > - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y
> > - remove double signoffs
> > - rebase on top of kvm-x86/next
> 
> I can't apply this series on top of current kvm-x86/next. On what exact
> commit the series is based on?

Note that kvm-x86/next is my tree at https://github.com/kvm-x86/linux/tree/next.
Are you pulling that, or are you based off kvm/next (Paolo's tree at
git://git.kernel.org/pub/scm/virt/kvm/kvm.git)?

Because this series applies for me on all of these tags from kvm-x86.

  kvm-x86-next-2024.02.22
  kvm-x86-next-2024.02.23
  kvm-x86-next-2024.02.26
  kvm-x86-next-2024.02.26-2
Bagas Sanjaya Feb. 28, 2024, 3:22 a.m. UTC | #3 
On Tue, Feb 27, 2024 at 09:49:24AM -0800, Sean Christopherson wrote:
> On Tue, Feb 27, 2024, Bagas Sanjaya wrote:
> > On Mon, Feb 26, 2024 at 02:03:29PM -0500, Paolo Bonzini wrote:
> > > v2->v3:
> > > - use u64_to_user_addr()
> > > - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y
> > > - remove double signoffs
> > > - rebase on top of kvm-x86/next
> > 
> > I can't apply this series on top of current kvm-x86/next. On what exact
> > commit the series is based on?
> 
> Note that kvm-x86/next is my tree at https://github.com/kvm-x86/linux/tree/next.
> Are you pulling that, or are you based off kvm/next (Paolo's tree at
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git)?

I pulled from the former.

> 
> Because this series applies for me on all of these tags from kvm-x86.
> 
>   kvm-x86-next-2024.02.22
>   kvm-x86-next-2024.02.23
>   kvm-x86-next-2024.02.26
>   kvm-x86-next-2024.02.26-2

Successfully applied against kvm-x86-next-2024.02.26 tag. Thanks for the
pointer!