linux-kernel - Re: [PATCH v3 00/15] KVM: SEV: allow customizing VMSA features

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zd1cDyyx65J1IVK1@archie.me>
Date: Tue, 27 Feb 2024 10:50:39 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Cc: seanjc@...gle.com, michael.roth@....com, aik@....com
Subject: Re: [PATCH v3 00/15] KVM: SEV: allow customizing VMSA features

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...

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)