#
4af663c2 |
|
01-May-2024 |
Michael Roth <michael.roth@amd.com> |
KVM: SEV: Allow per-guest configuration of GHCB protocol version The GHCB protocol version may be different from one guest to the next. Add a field to track it for each KVM instance and extend KVM_SEV_INIT2 to allow it to be configured by userspace. Now that all SEV-ES support for GHCB protocol version 2 is in place, go ahead and default to it when creating SEV-ES guests through the new KVM_SEV_INIT2 interface. Keep the older KVM_SEV_ES_INIT interface restricted to GHCB protocol version 1. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-ID: <20240501071048.2208265-5-michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
4f5defae |
|
04-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
KVM: SEV: introduce KVM_SEV_INIT2 operation The idea that no parameter would ever be necessary when enabling SEV or SEV-ES for a VM was decidedly optimistic. In fact, in some sense it's already a parameter whether SEV or SEV-ES is desired. Another possible source of variability 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. Create a new sub-operation for KVM_MEMORY_ENCRYPT_OP that can take a struct, and put the new op to work by including the VMSA features as a field of the struct. The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of supported VMSA features for backwards compatibility. The struct also includes the usual bells and whistles for future extensibility: a flags field that must be zero for now, and some padding at the end. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240404121327.3107131-13-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
ac5c4802 |
|
04-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
KVM: SEV: publish supported VMSA features Compute the set of features to be stored in the VMSA when KVM is initialized; move it from there into kvm_sev_info when SEV is initialized, and then into the initial VMSA. The new variable can then be used to return the set of supported features to userspace, via the KVM_GET_DEVICE_ATTR ioctl. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> Message-ID: <20240404121327.3107131-6-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
c20722c4 |
|
17-Mar-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
Documentation: kvm/sev: clarify usage of KVM_MEMORY_ENCRYPT_OP Explain that it operates on the VM file descriptor, and also clarify how detection of SEV operates on old kernels predating commit 2da1ed62d55c ("KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available"). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
19cebbab |
|
09-Feb-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
Documentation: kvm/sev: separate description of firmware The description of firmware is included part under the "SEV Key Management" header, part under the KVM_SEV_INIT ioctl. Put these two bits together and and rename "SEV Key Management" to what it actually is, namely a description of the KVM_MEMORY_ENCRYPT_OP API. Reviewed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
1e6115f5 |
|
24-Jun-2023 |
Changyuan Lyu <changyuanl@google.com> |
Documentation: KVM: SEV: add a missing backtick ``ENOTTY` -> ``ENOTTY``. Signed-off-by: Changyuan Lyu <changyuanl@google.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20230624165858.21777-1-changyuanl@google.com>
|
#
fbabc2ea |
|
25-Jan-2023 |
Wyes Karny <wyes.karny@amd.com> |
Documentation: KVM: Update AMD memory encryption link Update AMD memory encryption white-paper document link. Previous link is not available. Update new available link. Signed-off-by: Wyes Karny <wyes.karny@amd.com> Reviewed-by: Carlos Bilbao <carlos.bilbao@amd.com> Link: https://lore.kernel.org/r/20230125175948.21100-1-wyes.karny@amd.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
d8da2da2 |
|
16-Aug-2022 |
Jacky Li <jackyli@google.com> |
crypto: ccp - Initialize PSP when reading psp data file failed Currently the OS fails the PSP initialization when the file specified at 'init_ex_path' does not exist or has invalid content. However the SEV spec just requires users to allocate 32KB of 0xFF in the file, which can be taken care of by the OS easily. To improve the robustness during the PSP init, leverage the retry mechanism and continue the init process: Before the first INIT_EX call, if the content is invalid or missing, continue the process by feeding those contents into PSP instead of aborting. PSP will then override it with 32KB 0xFF and return SEV_RET_SECURE_DATA_INVALID status code. In the second INIT_EX call, this 32KB 0xFF content will then be fed and PSP will write the valid data to the file. In order to do this, sev_read_init_ex_file should only be called once for the first INIT_EX call. Calling it again for the second INIT_EX call will cause the invalid file content overwriting the valid 32KB 0xFF data provided by PSP in the first INIT_EX call. Co-developed-by: Peter Gonda <pgonda@google.com> Signed-off-by: Peter Gonda <pgonda@google.com> Signed-off-by: Jacky Li <jackyli@google.com> Reported-by: Alper Gun <alpergun@google.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
af105c9c |
|
06-Apr-2022 |
Like Xu <like.xu.linux@gmail.com> |
Documentation: KVM: Add SPDX-License-Identifier tag +new file mode 100644 +WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 +#27: FILE: Documentation/virt/kvm/x86/errata.rst:1: Opportunistically update all other non-added KVM documents and remove a new extra blank line at EOF for x86/errata.rst. Signed-off-by: Like Xu <likexu@tencent.com> Message-Id: <20220406063715.55625-5-likexu@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
daec8d40 |
|
21-Mar-2022 |
Paolo Bonzini <pbonzini@redhat.com> |
Documentation: KVM: add separate directories for architecture-specific documentation ARM already has an arm/ subdirectory, but s390 and x86 do not even though they have a relatively large number of files specific to them. Create new directories in Documentation/virt/kvm for these two architectures as well. While at it, group the API documentation and the developer documentation in the table of contents. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220322110712.222449-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|