| 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
| ||
|
Message-ID: <20171013185424.x6cwccs3lfgbhqvk@pd.tnic>
Date: Fri, 13 Oct 2017 20:54:24 +0200
From: Borislav Petkov <bp@...en8.de>
To: Brijesh Singh <brijesh.singh@....com>
Cc: x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Joerg Roedel <joro@...tes.org>, Borislav Petkov <bp@...e.de>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [Part2 PATCH v5 16/31] KVM: Define SEV key management command id
On Wed, Oct 04, 2017 at 08:13:57AM -0500, Brijesh Singh wrote:
> Define Secure Encrypted Virtualization (SEV) key management command id
> and structure. The command definition is available in SEV KM [1] spec
> 0.14 and Documentation/virtual/kvm/amd-memory-encryption.txt
>
> [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: "Radim Krčmář" <rkrcmar@...hat.com>
> Cc: Joerg Roedel <joro@...tes.org>
> Cc: Borislav Petkov <bp@...e.de>
> Cc: Tom Lendacky <thomas.lendacky@....com>
> Cc: x86@...nel.org
> Cc: kvm@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
> ---
> .../virtual/kvm/amd-memory-encryption.txt | 191 +++++++++++++++++++++
> include/uapi/linux/kvm.h | 79 +++++++++
> 2 files changed, 270 insertions(+)
Just formatting fixes:
---
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
index 8c79946b4d43..1ec5517f2948 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.txt
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -39,17 +39,16 @@ defined in the CPUID 0x8000001f[ecx] field.
SEV Key Management
------------------
-The Key management for the SEV guest is handled by a separate processor known as
-the AMD Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a
-secure key management interface to perform common hypervisor activities such as
-encrypting bootstrap code, snapshot, migrating and debugging the guest. For
-more information, see SEV Key Management spec at
+The SEV guest key management is handled by a separate processor called the AMD
+Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a secure
+key management interface to perform common hypervisor activities such as
+encrypting bootstrap code, snapshot, migrating and debugging the guest. For more
+information, see the SEV Key Management spec:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
-KVM implements the following commands to support SEV guests common lifecycle
-events such as launching, running, snapshotting, migrating and decommissioning
-guests.
+KVM implements the following commands to support common lifecycle events of SEV
+guests, such as launching, running, snapshotting, migrating and decommissioning.
1. KVM_SEV_INIT
@@ -68,22 +67,17 @@ context. To create the encryption context, user must provide a guest policy,
the owner's public Diffie-Hellman (PDH) key and session information.
struct kvm_sev_launch_start {
- /* if zero then firmware creates a new handle */
- __u32 handle;
+ __u32 handle; /* if zero then firmware creates a new handle */
+ __u32 policy; /* guest's policy */
- /* guest's policy */
- __u32 policy;
-
- /* userspace address pointing to the guest owner's PDH key */
- __u64 dh_uaddr;
+ __u64 dh_uaddr; /* userspace address pointing to the guest owner's PDH key */
__u32 dh_len;
- /* userspace address which points to the guest session information */
- __u64 session_addr;
+ __u64 session_addr; /* userspace address which points to the guest session information */
__u32 session_len;
};
-On success, the 'handle' field contain a new handle and on error, a negative value.
+On success, the 'handle' field contains a new handle and on error, a negative value.
For more details, see SEV spec Section 6.2.
@@ -92,17 +86,14 @@ For more details, see SEV spec Section 6.2.
Parameters (in): struct kvm_sev_launch_update_data
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting the memory region. It also
+The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting a memory region. It also
calculates a measurement of the memory contents. The measurement is a signature
of the memory contents that can be sent to the guest owner as an attestation
that the memory was encrypted correctly by the firmware.
struct kvm_sev_launch_update {
- /* userspace address need to be encrypted (must be 16-byte aligned) */
- __u64 uaddr;
-
- /* length of the data to be encrypted (must be 16-byte aligned) */
- __u32 len;
+ __u64 uaddr; /* userspace address to be encrypted (must be 16-byte aligned) */
+ __u32 len; /* length of the data to be encrypted (must be 16-byte aligned) */
};
For more details, see SEV spec Section 6.3.
@@ -112,22 +103,19 @@ For more details, see SEV spec Section 6.3.
Parameters (in): struct kvm_sev_launch_measure
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement
-of the data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA. The guest owner
-may wait to provide the guest with confidential information until it can
-verify the measurement. Since the guest owner knows the initial contents
-of the guest at boot, the measurement can be verified by comparing it to
-what the guest owner expects.
+The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement of the
+data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA command. The guest owner may
+wait to provide the guest with confidential information until it can verify the
+measurement. Since the guest owner knows the initial contents of the guest at
+boot, the measurement can be verified by comparing it to what the guest owner
+expects.
struct kvm_sev_launch_measure {
- /* where to copy the measurement */
- __u64 uaddr;
-
- /* length of measurement blob */
- __u32 len;
+ __u64 uaddr; /* where to copy the measurement */
+ __u32 len; /* length of measurement blob */
};
-For more details on the measurement verification flow, see SEV spec Section 6.4
+For more details on the measurement verification flow, see SEV spec Section 6.4.
5. KVM_SEV_LAUNCH_FINISH
@@ -145,14 +133,9 @@ The KVM_SEV_GUEST_STATUS command is used to retrieve status information about a
SEV-enabled guest.
struct kvm_sev_guest_status {
- /* guest handle */
- __u32 handle;
-
- /* guest policy */
- __u32 policy;
-
- /* guest state (see below) */
- __u8 state;
+ __u32 handle; /* guest handle */
+ __u32 policy; /* guest policy */
+ __u8 state; /* guest state (see enum below) */
};
SEV guest state:
@@ -175,16 +158,12 @@ The KVM_SEV_DEBUG_DECRYPT command can be used by the hypervisor to request the
firmware to decrypt the data at the given memory region.
struct kvm_sev_dbg {
- /* userspace address of data to decrypt */
- __u64 src_uaddr;
- /* userspace address of destination */
- __u64 dst_uaddr;
-
- /* length of memory region to decrypt */
- __u32 len;
+ __u64 src_uaddr; /* userspace address of data to decrypt */
+ __u64 dst_uaddr; /* userspace address of destination */
+ __u32 len; /* length of memory region to decrypt */
};
-The command returns an error if guest policy does not allow debugging.
+The command returns an error if the guest policy does not allow debugging.
8. KVM_SEV_DBG_ENCRYPT
@@ -195,35 +174,28 @@ The KVM_SEV_DEBUG_ENCRYPT command can be used by the hypervisor to request the
firmware to encrypt the data at the given memory region.
struct kvm_sev_dbg {
- /* userspace address of data to encrypt */
- __u64 src_uaddr;
- /* userspace address of destination */
- __u64 dst_uaddr;
-
- /* length of memory region to encrypt */
- __u32 len;
+ __u64 src_uaddr; /* userspace address of data to encrypt */
+ __u64 dst_uaddr; /* userspace address of destination */
+ __u32 len; /* length of memory region to encrypt */
};
-The command returns an error if guest policy does not allow debugging.
+The command returns an error if the guest policy does not allow debugging.
9. KVM_SEV_LAUNCH_SECRET
Parameters (in): struct kvm_sev_launch_secret
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject a secret
+The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject secret
data after the measurement has been validated by the guest owner.
struct kvm_sev_launch_secret {
- /* userspace address containing the packet header */
- __u64 hdr_uaddr;
+ __u64 hdr_uaddr; /* userspace address containing the packet header */
__u32 hdr_len;
- /* the guest memory region where the secret should be injected */
- __u64 guest_uaddr;
+ __u64 guest_uaddr; /* the guest memory region where the secret should be injected */
__u32 guest_len;
- /* the hypervisor memory region which contains the secret */
- __u64 trans_uaddr;
+ __u64 trans_uaddr; /* the hypervisor memory region which contains the secret */
__u32 trans_len;
};
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 115c75156711..d35fde050f3a 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1364,10 +1364,9 @@ struct kvm_enc_region {
__u64 size;
};
-#define KVM_MEMORY_ENCRYPT_REGISTER_REGION _IOR(KVMIO, 0xbb,\
- struct kvm_enc_region)
-#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
- struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_REGISTER_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
+
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
/* Guest initialization commands */
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists