* [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
@ 2017-09-19 20:45 ` Brijesh Singh
2017-09-29 6:54 ` Borislav Petkov
2017-10-04 10:11 ` [PATCH v5] " Borislav Petkov
2017-09-19 20:46 ` [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
` (27 subsequent siblings)
28 siblings, 2 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:45 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Borislav Petkov, Tom Lendacky, x86
Create a Documentation entry to describe the AMD Secure Encrypted
Virtualization (SEV) feature.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: kvm@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Documentation/virtual/kvm/00-INDEX | 3 +
.../virtual/kvm/amd-memory-encryption.txt | 210 +++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/virtual/kvm/amd-memory-encryption.txt
diff --git a/Documentation/virtual/kvm/00-INDEX b/Documentation/virtual/kvm/00-INDEX
index 69fe1a8b7ad1..3da73aabff5a 100644
--- a/Documentation/virtual/kvm/00-INDEX
+++ b/Documentation/virtual/kvm/00-INDEX
@@ -26,3 +26,6 @@ s390-diag.txt
- Diagnose hypercall description (for IBM S/390)
timekeeping.txt
- timekeeping virtualization for x86-based architectures.
+amd-memory-encryption.txt
+ - notes on AMD Secure Encrypted Virtualization feature and SEV firmware
+ command description
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
new file mode 100644
index 000000000000..5586d51a8983
--- /dev/null
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -0,0 +1,210 @@
+Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
+
+SEV is an extension to the AMD-V architecture which supports running virtual
+machines (VMs) under the control of a hypervisor. When enabled, the memory
+contents of VM will be transparently encrypted with a key unique to the VM.
+
+Hypervisor can determine the SEV support through the CPUID instruction. The CPUID
+function 0x8000001f reports information related to SEV:
+
+ 0x8000001f[eax]:
+ Bit[1] indicates support for SEV
+
+ [ecx]:
+ Bits[31:0] Number of encrypted guest supported simultaneously
+
+If support for SEV is present, MSR 0xc001_0010 (MSR_K8_SYSCFG) and MSR
+0xc001_0015 (MSR_K7_HWCR_SMMLOCK) can be used to determine if it can be enabled:
+
+ 0xc001_0010:
+ Bit[23] 0 = memory encryption can be enabled
+ 0 = memory encryption can not be enabled
+
+ 0xc001_0015:
+ Bit[0] 0 = memory encryption can not be enabled
+ 1 = memory encryption can be enabled
+
+When SEV support is available, it can be enabled in specific VM during the VMRUN
+instruction by setting SEV bit in VMCB offset 090h:
+
+ VMCB[0x90]:
+ Bit[1] 1 = Enable SEV
+
+SEV hardware uses ASIDs to associate a memory encryption key with a VM. Hence
+the ASID for the SEV enabled guests must be from 1 to a maximum value defined
+in the CPUID function 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
+
+http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+
+KVM implements the following commands to support SEV guests launch, migrate
+and save/restore.
+
+1. KVM_SEV_LAUNCH_START
+
+Parameters: struct kvm_sev_launch_start (in/out)
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_START command is used for creation the encryption 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 FW creates a new handle */
+ __u32 handle;
+
+ /* guest policy */
+ __u32 policy;
+
+ /* userspace address pointing to the guest owner's PDH key */
+ __u64 dh_uaddr;
+ __u32 dh_len;
+
+ /* userspace address which points to the guest session information */
+ __u64 session_addr;
+ __u32 session_len;
+};
+
+On success, the 'handle' field contain a new handle and on error, a negative value.
+
+For more details, see SEV spec Section 6.2.
+
+2. KVM_SEV_LAUNCH_UPDATE_DATA
+
+Parameters (in): struct kvm_sev_launch_update
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting the guest memory regions
+with the encryption context created using KVM_SEV_LAUNCH_START.
+
+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;
+};
+
+For more details, see SEV spec Section 6.3.
+
+3. KVM_SEV_LAUNCH_MEASURE
+
+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
+memory regions encrypted using KVM_SEV_LAUNCH_UPDATE_DATA.
+
+struct kvm_sev_launch_measure {
+ /* where to copy the measurement */
+ __u64 uaddr;
+
+ /* length of measurement blob */
+ __u32 len;
+};
+
+For more details on how the measurement can be used for attesation, see SEV
+spec Section 6.4.
+
+4. KVM_SEV_LAUNCH_FINISH
+
+Returns: 0 on success, -negative on error
+
+KVM_SEV_LAUNCH_FINISH command finalize the SEV guest launch process.
+
+5. KVM_SEV_GUEST_STATUS
+
+Parameters (out): struct kvm_sev_guest_status
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_GUEST_STATUS command is used to retrieve status information about an
+SEV-enabled guest..
+
+struct kvm_sev_guest_status {
+ /* guest handle */
+ __u32 handle;
+
+ /* guest policy */
+ __u32 policy;
+
+ /* guest state (see below) */
+ __u8 state;
+};
+
+SEV guest state:
+
+enum {
+ SEV_STATE_INVALID = 0;
+ SEV_STATE_LAUNCHING, /* guest is currently being launched */
+ SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */
+ SEV_STATE_RUNNING, /* guest is fully launched and running */
+ SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */
+ SEV_STATE_SENDING /* guest is getting migrated out another SEV machine */
+};
+
+6. KVM_SEV_DBG_DECRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_DEBUG_DECRYPT command is used for decrypting a memory region for the
+debug purposes.
+
+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;
+};
+
+The command returns an error if guest policy does not allow debugging.
+
+7. KVM_SEV_DBG_ENCRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_DEBUG_ENCRYPT command is used for encrypting a plaintext using the
+VM encryption key.
+
+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;
+};
+
+8. KVM_SEV_LAUNCH_SECRET
+
+Parameters (in): struct kvm_sev_launch_secret
+Returns: 0 on success, -negative on error
+
+Te KVM_SEV_LAUNCH_SECRET command can be used by hypevisor to inject a secret
+into the guest.
+
+struct kvm_sev_launch_secret {
+ /* userspace address containing the packet header */
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+
+ /* the guest memory region where the secret should be injected */
+ __u64 guest_uaddr;
+ __u32 guest_len;
+
+ /* the hypervisor memory region which contains the secret */
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-09-19 20:45 ` [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
@ 2017-09-29 6:54 ` Borislav Petkov
2017-10-02 11:52 ` Brijesh Singh
2017-10-04 10:11 ` [PATCH v5] " Borislav Petkov
1 sibling, 1 reply; 56+ messages in thread
From: Borislav Petkov @ 2017-09-29 6:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Tom Lendacky, x86
On Tue, Sep 19, 2017 at 03:45:59PM -0500, Brijesh Singh wrote:
> Create a Documentation entry to describe the AMD Secure Encrypted
> Virtualization (SEV) feature.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: kvm@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> Documentation/virtual/kvm/00-INDEX | 3 +
> .../virtual/kvm/amd-memory-encryption.txt | 210 +++++++++++++++++++++
> 2 files changed, 213 insertions(+)
> create mode 100644 Documentation/virtual/kvm/amd-memory-encryption.txt
Here's a diff which applies ontop of this one, it moves the KVM_SEV_*
commands to Documentation/virtual/kvm/api.txt where they're all together
in one place for obvious advantages.
Also I did some small cleanups while at it.
Notable is that the commands are a smaller number now and
KVM_SEV_RECEIVE_UPDATE_DATA, KVM_SEV_RECEIVE_START and a couple more are
missing.
On purpose?
---
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
index 5b38b4feb9b7..2f17400f5720 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.txt
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -1,16 +1,18 @@
Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
-SEV is an extension to the AMD-V architecture which supports running virtual
-machines (VMs) under the control of a hypervisor. When enabled, the memory
-contents of VM will be transparently encrypted with a key unique to the VM.
+SEV is an extension to the AMD-V architecture which supports running
+virtual machines (VMs) under the control of a hypervisor. When enabled,
+the memory contents of a VM will be transparently encrypted with a key
+unique to that VM.
-Hypervisor can determine the SEV support through the CPUID instruction. The CPUID
-function 0x8000001f reports information related to SEV:
+The hypervisor can determine the SEV support through the CPUID
+instruction. The CPUID function 0x8000001f reports information related
+to SEV:
0x8000001f[eax]:
Bit[1] indicates support for SEV
-
- 0x8000001f[ecx]:
+ ...
+ [ecx]:
Bits[31:0] Number of encrypted guests supported simultaneously
If support for SEV is present, MSR 0xc001_0010 (MSR_K8_SYSCFG) and MSR 0xc001_0015
@@ -24,8 +26,8 @@ If support for SEV is present, MSR 0xc001_0010 (MSR_K8_SYSCFG) and MSR 0xc001_00
Bit[0] 1 = memory encryption can be enabled
0 = memory encryption can not be enabled
-When SEV support is available, it can be enabled in a specific VM by setting SEV
-bit before executing VMRUN.
+When SEV support is available, it can be enabled in a specific VM by
+setting the SEV bit before executing VMRUN.
VMCB[0x90]:
Bit[1] 1 = SEV is enabled
@@ -45,182 +47,6 @@ more information, see SEV Key Management spec at
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.
-
-1. KVM_SEV_INIT
-
-Returns: 0 on success, -negative on error
-
-The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform
-context. In a typical workflow, this command should be the first command issued.
-
-2. KVM_SEV_LAUNCH_START
-
-Parameters: struct kvm_sev_launch_start (in/out)
-Returns: 0 on success, -negative on error
-
-The KVM_SEV_LAUNCH_START command is used for creating the memory encryption
-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;
-
- /* guest's policy */
- __u32 policy;
-
- /* userspace address pointing to the guest owner's PDH key */
- __u64 dh_uaddr;
- __u32 dh_len;
-
- /* userspace address which points to the guest session information */
- __u64 session_addr;
- __u32 session_len;
-};
-
-On success, the 'handle' field contain a new handle and on error, a negative value.
-
-For more details, see SEV spec Section 6.2.
-
-3. KVM_SEV_LAUNCH_UPDATE_DATA
-
-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
-calculates a measurement of the memory contents. The measurement is a signature
-of the memory contents that can be sent to the guest owners 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;
-};
-
-For more details, see SEV spec Section 6.3.
-
-4. KVM_SEV_LAUNCH_MEASURE
-
-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 expect.
-
-struct kvm_sev_launch_measure {
- /* where to copy the measurement */
- __u64 uaddr;
-
- /* length of measurement blob */
- __u32 len;
-};
-
-For more details on the measurement verification flow, see SEV spec Section 6.4
-
-5. KVM_SEV_LAUNCH_FINISH
-
-Returns: 0 on success, -negative on error
-
-After completion of the launch flow, the KVM_SEV_LAUNCH_FINISH command can be
-issued to make the guest ready for the execution.
-
-6. KVM_SEV_GUEST_STATUS
-
-Parameters (out): struct kvm_sev_guest_status
-Returns: 0 on success, -negative on error
-
-The KVM_SEV_GUEST_STATUS command is used to retrieve status information about an
-SEV-enabled guest..
-
-struct kvm_sev_guest_status {
- /* guest handle */
- __u32 handle;
-
- /* guest policy */
- __u32 policy;
-
- /* guest state (see below) */
- __u8 state;
-};
-
-SEV guest state:
-
-enum {
- SEV_STATE_INVALID = 0;
- SEV_STATE_LAUNCHING, /* guest is currently being launched */
- SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */
- SEV_STATE_RUNNING, /* guest is fully launched and running */
- SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */
- SEV_STATE_SENDING /* guest is getting migrated out to another SEV machine */
-};
-
-7. KVM_SEV_DBG_DECRYPT
-
-Parameters (in): struct kvm_sev_dbg
-Returns: 0 on success, -negative on error
-
-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;
-};
-
-The command returns an error if guest policy does not allow debugging.
-
-8. KVM_SEV_DBG_ENCRYPT
-
-Parameters (in): struct kvm_sev_dbg
-Returns: 0 on success, -negative on error
-
-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;
-};
-
-The command returns an error if 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
-
-Te KVM_SEV_LAUNCH_SECRET command can be used by the hypevisor to inject a 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;
- __u32 hdr_len;
-
- /* the guest memory region where the secret should be injected */
- __u64 guest_uaddr;
- __u32 guest_len;
-
- /* the hypervisor memory region which contains the secret */
- __u64 trans_uaddr;
- __u32 trans_len;
-};
+See Documentation/virtual/kvm/api.txt for the commands KVM implements to
+support common lifecycle events of SEV guests such as launching, running,
+snapshotting, migrating and decommissioning.
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e63a35fafef0..d48f338b67e0 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3390,6 +3390,183 @@ invalid, if invalid pages are written to (e.g. after the end of memory)
or if no page table is present for the addresses (e.g. when using
hugepages).
+4.109 KVM_SEV_INIT
+
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform
+context. In a typical workflow, this command should be the first command issued.
+
+4.110 KVM_SEV_LAUNCH_START
+
+Parameters: struct kvm_sev_launch_start (in/out)
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_START command is used for creating the memory encryption
+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;
+
+ /* guest's policy */
+ __u32 policy;
+
+ /* userspace address pointing to the guest owner's PDH key */
+ __u64 dh_uaddr;
+ __u32 dh_len;
+
+ /* userspace address which points to the guest session information */
+ __u64 session_addr;
+ __u32 session_len;
+};
+
+On success, the 'handle' field contain a new handle and on error, a negative value.
+
+For more details, see SEV spec Section 6.2.
+
+4.111 KVM_SEV_LAUNCH_UPDATE_DATA
+
+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
+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;
+};
+
+For more details, see SEV spec Section 6.3.
+
+4.112 KVM_SEV_LAUNCH_MEASURE
+
+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.
+
+struct kvm_sev_launch_measure {
+ /* where to copy the measurement */
+ __u64 uaddr;
+
+ /* length of measurement blob */
+ __u32 len;
+};
+
+For more details on the measurement verification flow, see SEV spec Section 6.4
+
+4.113 KVM_SEV_LAUNCH_FINISH
+
+Returns: 0 on success, -negative on error
+
+After completion of the launch flow, the KVM_SEV_LAUNCH_FINISH command can be
+issued to make the guest ready for the execution.
+
+4.114 KVM_SEV_GUEST_STATUS
+
+Parameters (out): struct kvm_sev_guest_status
+Returns: 0 on success, -negative on error
+
+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;
+};
+
+SEV guest state:
+
+enum {
+ SEV_STATE_INVALID = 0;
+ SEV_STATE_LAUNCHING, /* guest is currently being launched */
+ SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */
+ SEV_STATE_RUNNING, /* guest is fully launched and running */
+ SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */
+ SEV_STATE_SENDING /* guest is getting migrated out to another SEV machine */
+};
+
+4.115 KVM_SEV_DBG_DECRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+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;
+};
+
+The command returns an error if guest policy does not allow debugging.
+
+4.116 KVM_SEV_DBG_ENCRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+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;
+};
+
+The command returns an error if guest policy does not allow debugging.
+
+4.117 KVM_SEV_LAUNCH_SECRET
+
+Parameters (in): struct kvm_sev_launch_secret
+Returns: 0 on success, -negative on error
+
+Te KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject a 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;
+ __u32 hdr_len;
+
+ /* the guest memory region where the secret should be injected */
+ __u64 guest_uaddr;
+ __u32 guest_len;
+
+ /* the hypervisor memory region which contains the secret */
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
5. The kvm_run structure
------------------------
diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt
index afc41f544dab..b6b64b01692a 100644
--- a/Documentation/x86/amd-memory-encryption.txt
+++ b/Documentation/x86/amd-memory-encryption.txt
@@ -39,7 +39,7 @@ CPUID function 0x8000001f reports information related to SME:
0x8000001f[eax]:
Bit[0] indicates support for SME
Bit[1] indicates support for SEV
- 0x8000001f[ebx]:
+ ... [ebx]:
Bits[5:0] pagetable bit number used to activate memory
encryption
Bits[11:6] reduction in physical address space, in bits, when
@@ -50,14 +50,14 @@ CPUID function 0x8000001f reports information related to SME:
If support for SME is present, MSR 0xc00100010 (MSR_K8_SYSCFG) can be used to
determine if SME is enabled and/or to enable memory encryption:
- 0xc0010010:
+ 0xc001_0010:
Bit[23] 0 = memory encryption features are disabled
1 = memory encryption features are enabled
If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if
SEV is active:
- 0xc0010131:
+ 0xc001_0131:
Bit[0] 0 = memory encryption is not active
1 = memory encryption is active
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-09-29 6:54 ` Borislav Petkov
@ 2017-10-02 11:52 ` Brijesh Singh
2017-10-02 13:21 ` Borislav Petkov
0 siblings, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-10-02 11:52 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, linux-kernel, kvm, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Tom Lendacky, x86
On 9/29/17 1:54 AM, Borislav Petkov wrote:
---
>> Documentation/virtual/kvm/00-INDEX | 3 +
>> .../virtual/kvm/amd-memory-encryption.txt | 210 +++++++++++++++++++++
>> 2 files changed, 213 insertions(+)
>> create mode 100644 Documentation/virtual/kvm/amd-memory-encryption.txt
> Here's a diff which applies ontop of this one, it moves the KVM_SEV_*
> commands to Documentation/virtual/kvm/api.txt where they're all together
> in one place for obvious advantages.
Thank you for the patch. One of feedback in RFC patches was to put the
command id and their definitions in amd-memory-encryption.txt hence I
was trying to follow that recommendation. Most of ioctls I have seen in
api.txt are either common or architecture specific. These commands are
vendor specific and I was not sure if they belong to api.txt. I am okay
with moving the definition to api.txt in next patch and we can see if
kvm folks have any objections.
Are you okay if I move the command id definition documentation later in
the patch -- basically include it as part of 'KVM: Define SEV key
management command id' [1]
[1] https://marc.info/?l=kvm&m=150585445223846&w=2
> Also I did some small cleanups while at it.
> Notable is that the commands are a smaller number now and
> KVM_SEV_RECEIVE_UPDATE_DATA, KVM_SEV_RECEIVE_START and a couple more are
> missing.
>
> On purpose?
The series does not implement the migration commands yet hence I took it
off.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-10-02 11:52 ` Brijesh Singh
@ 2017-10-02 13:21 ` Borislav Petkov
0 siblings, 0 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-10-02 13:21 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Tom Lendacky, x86
On Mon, Oct 02, 2017 at 06:52:01AM -0500, Brijesh Singh wrote:
> Thank you for the patch. One of feedback in RFC patches was to put the
> command id and their definitions in amd-memory-encryption.txt hence I
> was trying to follow that recommendation. Most of ioctls I have seen in
> api.txt are either common or architecture specific. These commands are
> vendor specific and I was not sure if they belong to api.txt. I am okay
> with moving the definition to api.txt in next patch and we can see if
> kvm folks have any objections.
So api.txt has them all and this way you can grep them easily. Much
better than spreading stuff around.
But looking at it again, you have the actual ioctls
KVM_MEMORY_ENCRYPT_OP, KVM_MEMORY_ENCRYPT_{UN,}REGISTER_REGION
which are API so you could keep only those in api.txt but
add a sentence there saying that the commands are defined in
Documentation/virtual/kvm/amd-memory-encryption.txt
> The series does not implement the migration commands yet hence I took it
> off.
Ok.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-09-19 20:45 ` [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2017-09-29 6:54 ` Borislav Petkov
@ 2017-10-04 10:11 ` Borislav Petkov
1 sibling, 0 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-10-04 10:11 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Tom Lendacky, x86
Pasting v5 here.
> From: Brijesh Singh <brijesh.singh@amd.com>
>
> Create a Documentation entry to describe the AMD Secure Encrypted
> Virtualization (SEV) feature.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: kvm@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> Documentation/virtual/kvm/00-INDEX | 3 ++
> .../virtual/kvm/amd-memory-encryption.txt | 38 ++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
> create mode 100644 Documentation/virtual/kvm/amd-memory-encryption.txt
Nice and sweet.
Reviewed-by: Borislav Petkov <bp@suse.de>
(Leaving in the rest for reference).
> diff --git a/Documentation/virtual/kvm/00-INDEX b/Documentation/virtual/kvm/00-INDEX
> index 69fe1a8b7ad1..3da73aabff5a 100644
> --- a/Documentation/virtual/kvm/00-INDEX
> +++ b/Documentation/virtual/kvm/00-INDEX
> @@ -26,3 +26,6 @@ s390-diag.txt
> - Diagnose hypercall description (for IBM S/390)
> timekeeping.txt
> - timekeeping virtualization for x86-based architectures.
> +amd-memory-encryption.txt
> + - notes on AMD Secure Encrypted Virtualization feature and SEV firmware
> + command description
> diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
> new file mode 100644
> index 000000000000..26472b4cdbaf
> --- /dev/null
> +++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
> @@ -0,0 +1,38 @@
> +Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
> +
> +SEV is an extension to the AMD-V architecture which supports running
> +virtual machines (VMs) under the control of a hypervisor. When enabled,
> +the memory contents of a VM will be transparently encrypted with a key
> +unique to that VM.
> +
> +The hypervisor can determine the SEV support through the CPUID
> +instruction. The CPUID function 0x8000001f reports information related
> +to SEV:
> +
> + 0x8000001f[eax]:
> + Bit[1] indicates support for SEV
> + ...
> + [ecx]:
> + Bits[31:0] Number of encrypted guests supported simultaneously
> +
> +If support for SEV is present, MSR 0xc001_0010 (MSR_K8_SYSCFG) and MSR 0xc001_0015
> +(MSR_K7_HWCR) can be used to determine if it can be enabled:
> +
> + 0xc001_0010:
> + Bit[23] 1 = memory encryption can be enabled
> + 0 = memory encryption can not be enabled
> +
> + 0xc001_0015:
> + Bit[0] 1 = memory encryption can be enabled
> + 0 = memory encryption can not be enabled
> +
> +When SEV support is available, it can be enabled in a specific VM by
> +setting the SEV bit before executing VMRUN.
> +
> + VMCB[0x90]:
> + Bit[1] 1 = SEV is enabled
> + 0 = SEV is disabled
> +
> +SEV hardware uses ASIDs to associate a memory encryption key with a VM.
> +Hence, the ASID for the SEV-enabled guests must be from 1 to a maximum value
> +defined in the CPUID 0x8000001f[ecx] field.
> --
> 2.13.0
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-09-19 20:45 ` [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-29 12:19 ` Borislav Petkov
2017-09-19 20:46 ` [Part2 PATCH v4 03/29] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
` (26 subsequent siblings)
28 siblings, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Borislav Petkov, x86, Brijesh Singh
From: Tom Lendacky <thomas.lendacky@amd.com>
Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature. SEV is identified by
CPUID 0x8000001f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show the SEV feature
as available if reported by CPUID and enabled by BIOS.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: kvm@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/cpu/amd.c | 66 ++++++++++++++++++++++++++------------
arch/x86/kernel/cpu/scattered.c | 1 +
4 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 2519c6c801c9..759d29c37686 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -197,6 +197,7 @@
#define X86_FEATURE_HW_PSTATE ( 7*32+ 8) /* AMD HW-PState */
#define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
#define X86_FEATURE_SME ( 7*32+10) /* AMD Secure Memory Encryption */
+#define X86_FEATURE_SEV ( 7*32+11) /* AMD Secure Encrypted Virtualization */
#define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory Number */
#define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 17f5c12e1afd..e399d68029a9 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -378,6 +378,8 @@
#define MSR_K7_PERFCTR3 0xc0010007
#define MSR_K7_CLK_CTL 0xc001001b
#define MSR_K7_HWCR 0xc0010015
+#define MSR_K7_HWCR_SMMLOCK_BIT 0
+#define MSR_K7_HWCR_SMMLOCK BIT_ULL(MSR_K7_HWCR_SMMLOCK_BIT)
#define MSR_K7_FID_VID_CTL 0xc0010041
#define MSR_K7_FID_VID_STATUS 0xc0010042
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9862e2cd6d93..48820d8c006b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -556,6 +556,51 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
}
}
+static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
+{
+ u64 msr;
+
+ /*
+ * BIOS support is required for SME and SEV.
+ * For SME: If BIOS has enabled SME then adjust x86_phys_bits by
+ * the SME physical address space reduction value.
+ * If BIOS has not enabled SME then don't advertise the
+ * SME feature (set in scattered.c).
+ * For SEV: If BIOS has not enabled SEV then don't advertise the
+ * SEV feature (set in scattered.c).
+ *
+ * In all cases, since support for SME and SEV requires long mode,
+ * don't advertise the feature under CONFIG_X86_32.
+ */
+ if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) {
+ /* Check if memory encryption is enabled */
+ rdmsrl(MSR_K8_SYSCFG, msr);
+ if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
+ goto clear_all;
+
+ /*
+ * Always adjust physical address bits. Even though this
+ * will be a value above 32-bits this is still done for
+ * CONFIG_X86_32 so that accurate values are reported.
+ */
+ c->x86_phys_bits -= (cpuid_ebx(0x8000001f) >> 6) & 0x3f;
+
+ if (IS_ENABLED(CONFIG_X86_32))
+ goto clear_all;
+
+ rdmsrl(MSR_K7_HWCR, msr);
+ if (!(msr & MSR_K7_HWCR_SMMLOCK))
+ goto clear_sev;
+
+ return;
+
+clear_all:
+ clear_cpu_cap(c, X86_FEATURE_SME);
+clear_sev:
+ clear_cpu_cap(c, X86_FEATURE_SEV);
+ }
+}
+
static void early_init_amd(struct cpuinfo_x86 *c)
{
u32 dummy;
@@ -627,26 +672,7 @@ static void early_init_amd(struct cpuinfo_x86 *c)
if (cpu_has_amd_erratum(c, amd_erratum_400))
set_cpu_bug(c, X86_BUG_AMD_E400);
- /*
- * BIOS support is required for SME. If BIOS has enabled SME then
- * adjust x86_phys_bits by the SME physical address space reduction
- * value. If BIOS has not enabled SME then don't advertise the
- * feature (set in scattered.c). Also, since the SME support requires
- * long mode, don't advertise the feature under CONFIG_X86_32.
- */
- if (cpu_has(c, X86_FEATURE_SME)) {
- u64 msr;
-
- /* Check if SME is enabled */
- rdmsrl(MSR_K8_SYSCFG, msr);
- if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
- c->x86_phys_bits -= (cpuid_ebx(0x8000001f) >> 6) & 0x3f;
- if (IS_ENABLED(CONFIG_X86_32))
- clear_cpu_cap(c, X86_FEATURE_SME);
- } else {
- clear_cpu_cap(c, X86_FEATURE_SME);
- }
- }
+ early_detect_mem_encrypt(c);
}
static void init_amd_k8(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 05459ad3db46..63a78d5fe505 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -32,6 +32,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_CPB, CPUID_EDX, 9, 0x80000007, 0 },
{ X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 },
{ X86_FEATURE_SME, CPUID_EAX, 0, 0x8000001f, 0 },
+ { X86_FEATURE_SEV, CPUID_EAX, 1, 0x8000001f, 0 },
{ 0, 0, 0, 0, 0 }
};
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
2017-09-19 20:46 ` [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
@ 2017-09-29 12:19 ` Borislav Petkov
2017-09-29 22:44 ` Brijesh Singh
0 siblings, 1 reply; 56+ messages in thread
From: Borislav Petkov @ 2017-09-29 12:19 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Tom Lendacky, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
x86
On Tue, Sep 19, 2017 at 03:46:00PM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature. SEV is identified by
> CPUID 0x8000001f, but requires BIOS support to enable it (set bit 23 of
> MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show the SEV feature
> as available if reported by CPUID and enabled by BIOS.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: kvm@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/msr-index.h | 2 ++
> arch/x86/kernel/cpu/amd.c | 66 ++++++++++++++++++++++++++------------
> arch/x86/kernel/cpu/scattered.c | 1 +
> 4 files changed, 50 insertions(+), 20 deletions(-)
This one was in the Part1 set, right? It landed here for whatever
reason...
In any case:
Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
2017-09-29 12:19 ` Borislav Petkov
@ 2017-09-29 22:44 ` Brijesh Singh
2017-09-30 8:02 ` Borislav Petkov
0 siblings, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-09-29 22:44 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, linux-kernel, kvm, Tom Lendacky, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
x86
On 09/29/2017 07:19 AM, Borislav Petkov wrote:
...
>
> This one was in the Part1 set, right? It landed here for whatever
> reason...
>
Part1 is based on tip/master and Part2 is based on kvm/master.
With the current division, we should be able to compile and run part1
and part2 independently. This patch defines X86_FEATURE_SEV which is
currently been used by svm.c hence I kept the patch in Part2.
If we move it in Part1 then Part2 build will fail -- I am okay with
including it as a pre-cursor to Part2 series. Is this something acceptable?
-Brijesh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
2017-09-29 22:44 ` Brijesh Singh
@ 2017-09-30 8:02 ` Borislav Petkov
0 siblings, 0 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-09-30 8:02 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Tom Lendacky, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
x86
On Fri, Sep 29, 2017 at 05:44:24PM -0500, Brijesh Singh wrote:
> Part1 is based on tip/master and Part2 is based on kvm/master.
>
> With the current division, we should be able to compile and run part1
> and part2 independently. This patch defines X86_FEATURE_SEV which is
> currently been used by svm.c hence I kept the patch in Part2.
>
> If we move it in Part1 then Part2 build will fail -- I am okay with
> including it as a pre-cursor to Part2 series. Is this something acceptable?
No no, don't do anything. I was just wondering about the reason for the move.
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 PATCH v4 03/29] kvm: svm: prepare for new bit definition in nested_ctl
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-09-19 20:45 ` [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 04/29] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
` (25 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, x86, Brijesh Singh
From: Tom Lendacky <thomas.lendacky@amd.com>
Currently the nested_ctl variable in the vmcb_control_area structure is
used to indicate nested paging support. The nested paging support field
is actually defined as bit 0 of the field. In order to support a new
feature flag the usage of the nested_ctl and nested paging support must
be converted to operate on a single bit.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
arch/x86/include/asm/svm.h | 2 ++
arch/x86/kvm/svm.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 14835dd205a5..5e3244724c9d 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -145,6 +145,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
#define SVM_VM_CR_SVM_LOCK_MASK 0x0008ULL
#define SVM_VM_CR_SVM_DIS_MASK 0x0010ULL
+#define SVM_NESTED_CTL_NP_ENABLE BIT(0)
+
struct __attribute__ ((__packed__)) vmcb_seg {
u16 selector;
u16 attrib;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0e68f0b3cbf7..8186b8d7c469 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1296,7 +1296,7 @@ static void init_vmcb(struct vcpu_svm *svm)
if (npt_enabled) {
/* Setup VMCB for Nested Paging */
- control->nested_ctl = 1;
+ control->nested_ctl |= SVM_NESTED_CTL_NP_ENABLE;
clr_intercept(svm, INTERCEPT_INVLPG);
clr_exception_intercept(svm, PF_VECTOR);
clr_cr_intercept(svm, INTERCEPT_CR3_READ);
@@ -2910,7 +2910,8 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
if (vmcb->control.asid == 0)
return false;
- if (vmcb->control.nested_ctl && !npt_enabled)
+ if ((vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) &&
+ !npt_enabled)
return false;
return true;
@@ -2985,7 +2986,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
else
svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
- if (nested_vmcb->control.nested_ctl) {
+ if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) {
kvm_mmu_unload(&svm->vcpu);
svm->nested.nested_cr3 = nested_vmcb->control.nested_cr3;
nested_svm_init_mmu_context(&svm->vcpu);
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 04/29] kvm: svm: Add SEV feature definitions to KVM
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (2 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 03/29] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
` (24 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, x86, Brijesh Singh
From: Tom Lendacky <thomas.lendacky@amd.com>
Define the SEV enable bit for the VMCB control structure. The hypervisor
will use this bit to enable SEV in the guest.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
arch/x86/include/asm/svm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 5e3244724c9d..e9899ed67c70 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -146,6 +146,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
#define SVM_VM_CR_SVM_DIS_MASK 0x0010ULL
#define SVM_NESTED_CTL_NP_ENABLE BIT(0)
+#define SVM_NESTED_CTL_SEV_ENABLE BIT(1)
struct __attribute__ ((__packed__)) vmcb_seg {
u16 selector;
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (3 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 04/29] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-29 15:16 ` Borislav Petkov
2017-10-02 16:43 ` [Part2 Patch v4.2] " Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 06/29] ccp: crypto: Define SEV key management command id Brijesh Singh
` (23 subsequent siblings)
28 siblings, 2 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
Platform Security Processor (PSP) is part of AMD Secure Processor (AMD-SP),
PSP is a dedicated processor that provides the support for key management
commands in a Secure Encrypted Virtualiztion (SEV) mode, along with
software-based Trusted Executation Environment (TEE) to enable the
third-party trusted applications.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/Kconfig | 11 +++++
drivers/crypto/ccp/Makefile | 1 +
drivers/crypto/ccp/psp-dev.c | 111 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 61 ++++++++++++++++++++++++
drivers/crypto/ccp/sp-dev.c | 32 +++++++++++++
drivers/crypto/ccp/sp-dev.h | 27 ++++++++++-
drivers/crypto/ccp/sp-pci.c | 46 ++++++++++++++++++
7 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccp/psp-dev.c
create mode 100644 drivers/crypto/ccp/psp-dev.h
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 6d626606b9c5..1d927e13bf31 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -32,3 +32,14 @@ config CRYPTO_DEV_CCP_CRYPTO
Support for using the cryptographic API with the AMD Cryptographic
Coprocessor. This module supports offload of SHA and AES algorithms.
If you choose 'M' here, this module will be called ccp_crypto.
+
+config CRYPTO_DEV_SP_PSP
+ bool "Platform Security Processor (PSP) device"
+ default y
+ depends on CRYPTO_DEV_CCP_DD
+ help
+ Provide the support for AMD Platform Security Processor (PSP). PSP is
+ a dedicated processor that provides the support for key management
+ commands in in a Secure Encrypted Virtualiztion (SEV) mode, along with
+ software-based Trusted Executation Environment (TEE) to enable the
+ third-party trusted applications.
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 57f8debfcfb3..008bae7e26ec 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -7,6 +7,7 @@ ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
ccp-dmaengine.o \
ccp-debugfs.o
ccp-$(CONFIG_PCI) += sp-pci.o
+ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o
obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
new file mode 100644
index 000000000000..e60e53272e71
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -0,0 +1,111 @@
+/*
+ * AMD Platform Security Processor (PSP) interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/ccp.h>
+
+#include "sp-dev.h"
+#include "psp-dev.h"
+
+const struct psp_vdata psp_entry = {
+ .offset = 0x10500,
+};
+
+static struct psp_device *psp_alloc_struct(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+
+ psp = devm_kzalloc(dev, sizeof(*psp), GFP_KERNEL);
+ if (!psp)
+ return NULL;
+
+ psp->dev = dev;
+ psp->sp = sp;
+
+ snprintf(psp->name, sizeof(psp->name), "psp-%u", sp->ord);
+
+ return psp;
+}
+
+irqreturn_t psp_irq_handler(int irq, void *data)
+{
+ return IRQ_HANDLED;
+}
+
+int psp_dev_init(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+ int ret;
+
+ ret = -ENOMEM;
+ psp = psp_alloc_struct(sp);
+ if (!psp)
+ goto e_err;
+ sp->psp_data = psp;
+
+ psp->vdata = (struct psp_vdata *)sp->dev_vdata->psp_vdata;
+ if (!psp->vdata) {
+ ret = -ENODEV;
+ dev_err(dev, "missing driver data\n");
+ goto e_err;
+ }
+
+ psp->io_regs = sp->io_map + psp->vdata->offset;
+
+ /* Disable and clear interrupts until ready */
+ iowrite32(0, psp->io_regs + PSP_P2CMSG_INTEN);
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ dev_dbg(dev, "requesting an IRQ ...\n");
+ /* Request an irq */
+ ret = sp_request_psp_irq(psp->sp, psp_irq_handler, psp->name, psp);
+ if (ret) {
+ dev_err(dev, "psp: unable to allocate an IRQ\n");
+ goto e_err;
+ }
+
+ sp_set_psp_master(sp);
+
+ /* Enable interrupt */
+ dev_dbg(dev, "Enabling interrupts ...\n");
+ iowrite32(7, psp->io_regs + PSP_P2CMSG_INTEN);
+
+ dev_notice(dev, "psp enabled\n");
+
+ return 0;
+
+e_err:
+ sp->psp_data = NULL;
+
+ dev_notice(dev, "psp initialization failed\n");
+
+ return ret;
+}
+
+void psp_dev_destroy(struct sp_device *sp)
+{
+ struct psp_device *psp = sp->psp_data;
+
+ sp_free_psp_irq(sp, psp);
+}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
new file mode 100644
index 000000000000..d53970ef5960
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -0,0 +1,61 @@
+/*
+ * AMD Platform Security Processor (PSP) interface driver
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_DEV_H__
+#define __PSP_DEV_H__
+
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/spinlock.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/wait.h>
+#include <linux/dmapool.h>
+#include <linux/hw_random.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/dmaengine.h>
+
+#include "sp-dev.h"
+
+#define PSP_P2CMSG_INTEN 0x0110
+#define PSP_P2CMSG_INTSTS 0x0114
+
+#define PSP_C2PMSG_ATTR_0 0x0118
+#define PSP_C2PMSG_ATTR_1 0x011c
+#define PSP_C2PMSG_ATTR_2 0x0120
+#define PSP_C2PMSG_ATTR_3 0x0124
+#define PSP_P2CMSG_ATTR_0 0x0128
+
+#define PSP_CMDRESP_CMD_SHIFT 16
+#define PSP_CMDRESP_IOC BIT(0)
+#define PSP_CMDRESP_RESP BIT(31)
+#define PSP_CMDRESP_ERR_MASK 0xffff
+
+#define MAX_PSP_NAME_LEN 16
+
+struct psp_device {
+ struct list_head entry;
+
+ struct psp_vdata *vdata;
+ char name[MAX_PSP_NAME_LEN];
+
+ struct device *dev;
+ struct sp_device *sp;
+
+ void __iomem *io_regs;
+};
+
+extern const struct psp_vdata psp_entry;
+
+#endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index bef387c8abfd..8487454664d3 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -198,6 +198,8 @@ int sp_init(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_init(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_init(sp);
return 0;
}
@@ -206,6 +208,9 @@ void sp_destroy(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_destroy(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_destroy(sp);
+
sp_del_device(sp);
}
@@ -237,6 +242,33 @@ int sp_resume(struct sp_device *sp)
}
#endif
+struct sp_device *sp_get_psp_master_device(void)
+{
+ struct sp_device *i, *ret = NULL;
+ unsigned long flags;
+
+ write_lock_irqsave(&sp_unit_lock, flags);
+ if (list_empty(&sp_units))
+ goto unlock;
+
+ list_for_each_entry(i, &sp_units, entry) {
+ if (i->psp_data)
+ break;
+ }
+
+ if (i->get_psp_master_device)
+ ret = i->get_psp_master_device();
+unlock:
+ write_unlock_irqrestore(&sp_unit_lock, flags);
+ return ret;
+}
+
+void sp_set_psp_master(struct sp_device *sp)
+{
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+}
+
static int __init sp_mod_init(void)
{
#ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 5ab486ade1ad..be09905f06c2 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,19 @@ struct ccp_vdata {
const unsigned int offset;
const unsigned int rsamax;
};
+
+struct psp_vdata {
+ const unsigned int version;
+ const struct psp_actions *perform;
+ const unsigned int offset;
+};
+
/* Structure to hold SP device data */
struct sp_dev_vdata {
const unsigned int bar;
const struct ccp_vdata *ccp_vdata;
- void *psp_vdata;
+ const struct psp_vdata *psp_vdata;
};
struct sp_device {
@@ -68,6 +75,10 @@ struct sp_device {
/* DMA caching attribute support */
unsigned int axcache;
+ /* get and set master device */
+ struct sp_device*(*get_psp_master_device)(void);
+ void (*set_psp_master_device)(struct sp_device *);
+
bool irq_registered;
bool use_tasklet;
@@ -103,6 +114,8 @@ void sp_free_ccp_irq(struct sp_device *sp, void *data);
int sp_request_psp_irq(struct sp_device *sp, irq_handler_t handler,
const char *name, void *data);
void sp_free_psp_irq(struct sp_device *sp, void *data);
+void sp_set_psp_master(struct sp_device *sp);
+struct sp_device *sp_get_psp_master_device(void);
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
@@ -130,4 +143,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
}
#endif /* CONFIG_CRYPTO_DEV_SP_CCP */
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+
+int psp_dev_init(struct sp_device *sp);
+void psp_dev_destroy(struct sp_device *sp);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_dev_destroy(struct sp_device *sp) { }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 9859aa683a28..20a0f3543cf4 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -25,6 +25,7 @@
#include <linux/ccp.h>
#include "ccp-dev.h"
+#include "psp-dev.h"
#define MSIX_VECTORS 2
@@ -32,6 +33,7 @@ struct sp_pci {
int msix_count;
struct msix_entry msix_entry[MSIX_VECTORS];
};
+static struct sp_device *sp_dev_master;
static int sp_get_msix_irqs(struct sp_device *sp)
{
@@ -108,6 +110,45 @@ static void sp_free_irqs(struct sp_device *sp)
sp->psp_irq = 0;
}
+static bool sp_pci_is_master(struct sp_device *sp)
+{
+ struct device *dev_cur, *dev_new;
+ struct pci_dev *pdev_cur, *pdev_new;
+
+ dev_new = sp->dev;
+ dev_cur = sp_dev_master->dev;
+
+ pdev_new = to_pci_dev(dev_new);
+ pdev_cur = to_pci_dev(dev_cur);
+
+ if (pdev_new->bus->number < pdev_cur->bus->number)
+ return true;
+
+ if (PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn))
+ return true;
+
+ if (PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn))
+ return true;
+
+ return false;
+}
+
+static void psp_set_master(struct sp_device *sp)
+{
+ if (!sp_dev_master) {
+ sp_dev_master = sp;
+ return;
+ }
+
+ if (sp_pci_is_master(sp))
+ sp_dev_master = sp;
+}
+
+static struct sp_device *psp_get_master(void)
+{
+ return sp_dev_master;
+}
+
static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct sp_device *sp;
@@ -166,6 +207,8 @@ static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto e_err;
pci_set_master(pdev);
+ sp->set_psp_master_device = psp_set_master;
+ sp->get_psp_master_device = psp_get_master;
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48));
if (ret) {
@@ -237,6 +280,9 @@ static const struct sp_dev_vdata dev_vdata[] = {
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
.ccp_vdata = &ccpv5a,
#endif
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+ .psp_vdata = &psp_entry
+#endif
},
{
.bar = 2,
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-19 20:46 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-09-29 15:16 ` Borislav Petkov
2017-09-29 16:23 ` [Part2 PATCH v4.1 05/30] " Brijesh Singh
2017-09-30 15:55 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-10-02 16:43 ` [Part2 Patch v4.2] " Brijesh Singh
1 sibling, 2 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-09-29 15:16 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Tue, Sep 19, 2017 at 03:46:03PM -0500, Brijesh Singh wrote:
> Platform Security Processor (PSP) is part of AMD Secure Processor (AMD-SP),
The Platform...
> PSP is a dedicated processor that provides the support for key management
> commands in a Secure Encrypted Virtualiztion (SEV) mode, along with
Virtualization
Is integrating that spellchecker hard? Because what I do, for example,
is press F7 in vim when I've written the commit message. And F7 is
mapped to:
map <F7> :set spell! spelllang=en_us spellfile=~/.vim/spellfile.add<CR><Bar>:echo "spellcheck: " . strpart("offon", 3 * &spell, 3)<CR>
in my .vimrc
And I'm pretty sure you can do a similar thing with other editors.
> software-based Trusted Executation Environment (TEE) to enable the
> third-party trusted applications.
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Gary Hook <gary.hook@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> drivers/crypto/ccp/Kconfig | 11 +++++
> drivers/crypto/ccp/Makefile | 1 +
> drivers/crypto/ccp/psp-dev.c | 111 +++++++++++++++++++++++++++++++++++++++++++
> drivers/crypto/ccp/psp-dev.h | 61 ++++++++++++++++++++++++
> drivers/crypto/ccp/sp-dev.c | 32 +++++++++++++
> drivers/crypto/ccp/sp-dev.h | 27 ++++++++++-
> drivers/crypto/ccp/sp-pci.c | 46 ++++++++++++++++++
> 7 files changed, 288 insertions(+), 1 deletion(-)
> create mode 100644 drivers/crypto/ccp/psp-dev.c
> create mode 100644 drivers/crypto/ccp/psp-dev.h
>
> diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> index 6d626606b9c5..1d927e13bf31 100644
> --- a/drivers/crypto/ccp/Kconfig
> +++ b/drivers/crypto/ccp/Kconfig
> @@ -32,3 +32,14 @@ config CRYPTO_DEV_CCP_CRYPTO
> Support for using the cryptographic API with the AMD Cryptographic
> Coprocessor. This module supports offload of SHA and AES algorithms.
> If you choose 'M' here, this module will be called ccp_crypto.
> +
> +config CRYPTO_DEV_SP_PSP
> + bool "Platform Security Processor (PSP) device"
> + default y
> + depends on CRYPTO_DEV_CCP_DD
So this last symbol CRYPTO_DEV_CCP_DD is default m and it doesn't depend
on anything. And I'm pretty sure it should depend on CPU_SUP_AMD as this
is AMD-specific hw. You can add that dependency in a prepatch.
And what happened to adding dependencies on CONFIG_KVM_AMD? Or can you
use the PSP without virtualization in any sensible way?
> + help
> + Provide the support for AMD Platform Security Processor (PSP). PSP is
... for the AMD ... The PSP ...
> + a dedicated processor that provides the support for key management
that provides support for
> + commands in in a Secure Encrypted Virtualiztion (SEV) mode, along with
... in Secure Encrypted Virtualization
> + software-based Trusted Executation Environment (TEE) to enable the
> + third-party trusted applications.
> diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
> index 57f8debfcfb3..008bae7e26ec 100644
> --- a/drivers/crypto/ccp/Makefile
> +++ b/drivers/crypto/ccp/Makefile
> @@ -7,6 +7,7 @@ ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
> ccp-dmaengine.o \
> ccp-debugfs.o
> ccp-$(CONFIG_PCI) += sp-pci.o
> +ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o
>
> obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
> ccp-crypto-objs := ccp-crypto-main.o \
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> new file mode 100644
> index 000000000000..e60e53272e71
> --- /dev/null
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -0,0 +1,111 @@
> +/*
> + * AMD Platform Security Processor (PSP) interface
> + *
> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/kthread.h>
> +#include <linux/sched.h>
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/spinlock_types.h>
> +#include <linux/types.h>
> +#include <linux/mutex.h>
> +#include <linux/delay.h>
> +#include <linux/hw_random.h>
> +#include <linux/ccp.h>
> +
> +#include "sp-dev.h"
> +#include "psp-dev.h"
> +
> +const struct psp_vdata psp_entry = {
> + .offset = 0x10500,
> +};
> +
> +static struct psp_device *psp_alloc_struct(struct sp_device *sp)
> +{
> + struct device *dev = sp->dev;
> + struct psp_device *psp;
> +
> + psp = devm_kzalloc(dev, sizeof(*psp), GFP_KERNEL);
> + if (!psp)
> + return NULL;
> +
> + psp->dev = dev;
> + psp->sp = sp;
> +
> + snprintf(psp->name, sizeof(psp->name), "psp-%u", sp->ord);
> +
> + return psp;
> +}
> +
> +irqreturn_t psp_irq_handler(int irq, void *data)
Not static because... ?
> +{
> + return IRQ_HANDLED;
> +}
> +
> +int psp_dev_init(struct sp_device *sp)
> +{
> + struct device *dev = sp->dev;
> + struct psp_device *psp;
> + int ret;
> +
> + ret = -ENOMEM;
> + psp = psp_alloc_struct(sp);
> + if (!psp)
> + goto e_err;
<---- newline here. I already pointed this out last time. Please be more
careful when incorporating feedback. This is not the first time I'm
writing this. :-\
> + sp->psp_data = psp;
> +
> + psp->vdata = (struct psp_vdata *)sp->dev_vdata->psp_vdata;
> + if (!psp->vdata) {
> + ret = -ENODEV;
> + dev_err(dev, "missing driver data\n");
> + goto e_err;
> + }
> +
> + psp->io_regs = sp->io_map + psp->vdata->offset;
> +
> + /* Disable and clear interrupts until ready */
> + iowrite32(0, psp->io_regs + PSP_P2CMSG_INTEN);
> + iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTSTS);
> +
> + dev_dbg(dev, "requesting an IRQ ...\n");
> + /* Request an irq */
> + ret = sp_request_psp_irq(psp->sp, psp_irq_handler, psp->name, psp);
> + if (ret) {
> + dev_err(dev, "psp: unable to allocate an IRQ\n");
> + goto e_err;
> + }
> +
> + sp_set_psp_master(sp);
>From last review:
> So this function is called only once and declared somewhere else. You
> could simply do here:
>
> if (sp->set_psp_master_device)
> sp->set_psp_master_device(sp);
>
> and get rid of one more global function.
and you said:
> Sure I can do that.
> +
> + /* Enable interrupt */
> + dev_dbg(dev, "Enabling interrupts ...\n");
That statement is superfluous...
> + iowrite32(7, psp->io_regs + PSP_P2CMSG_INTEN);
> +
> + dev_notice(dev, "psp enabled\n");
... as this will issue anyway and there are no conditional code paths
in-between.
> +
> + return 0;
> +
> +e_err:
> + sp->psp_data = NULL;
> +
> + dev_notice(dev, "psp initialization failed\n");
> +
> + return ret;
> +}
> +
> +void psp_dev_destroy(struct sp_device *sp)
> +{
> + struct psp_device *psp = sp->psp_data;
> +
> + sp_free_psp_irq(sp, psp);
> +}
So I'm going to stop right here. Please go over
https://lkml.kernel.org/r/20170907142737.g4aot7xatyopdfwp@pd.tnic
make sure you've addressed *every* piece of feedback and then send me a
v4.1 for review.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread* [Part2 PATCH v4.1 05/30] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-29 15:16 ` Borislav Petkov
@ 2017-09-29 16:23 ` Brijesh Singh
2017-09-30 8:30 ` [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Borislav Petkov
2017-09-30 15:55 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
1 sibling, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-09-29 16:23 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The Platform Security Processor (PSP) is part of AMD Secure Processor
(AMD-SP), PSP is a dedicated processor that provides the support for
key management commands in a Secure Encrypted Virtualization (SEV) mode,
along with software-based Trusted Execution Environment (TEE) to enable
the third-party trusted applications.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Hi Boris,
I have been going through feedbacks and issues reported by kbuild robot and
have been making the fixes at:
repo: https://github.com/codomania/kvm.git
branch: sev-v4-p2+fixes
After I am finished with all the fixes then will submit v5 part2.
In meantime, if you don't mind then can you look at updated patches
on sev-v4-p2+fixes branch or you can just wait for me to submit v5.
thank you very much.
-Brijesh
drivers/crypto/ccp/Kconfig | 11 +++++
drivers/crypto/ccp/Makefile | 1 +
drivers/crypto/ccp/psp-dev.c | 113 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 61 +++++++++++++++++++++++
drivers/crypto/ccp/sp-dev.c | 26 ++++++++++
drivers/crypto/ccp/sp-dev.h | 26 +++++++++-
drivers/crypto/ccp/sp-pci.c | 46 ++++++++++++++++++
7 files changed, 283 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccp/psp-dev.c
create mode 100644 drivers/crypto/ccp/psp-dev.h
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 6d626606b9c5..627f3e61dcac 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -32,3 +32,14 @@ config CRYPTO_DEV_CCP_CRYPTO
Support for using the cryptographic API with the AMD Cryptographic
Coprocessor. This module supports offload of SHA and AES algorithms.
If you choose 'M' here, this module will be called ccp_crypto.
+
+config CRYPTO_DEV_SP_PSP
+ bool "Platform Security Processor (PSP) device"
+ default y
+ depends on CRYPTO_DEV_CCP_DD
+ help
+ Provide the support for AMD Platform Security Processor (PSP). PSP is
+ a dedicated processor that provides the support for key management
+ commands in a Secure Encrypted Virtualiztion (SEV) mode, along with
+ software-based Trusted Execution Environment (TEE) to enable the
+ third-party trusted applications.
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 57f8debfcfb3..008bae7e26ec 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -7,6 +7,7 @@ ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
ccp-dmaengine.o \
ccp-debugfs.o
ccp-$(CONFIG_PCI) += sp-pci.o
+ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o
obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
new file mode 100644
index 000000000000..b201c524c28f
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -0,0 +1,113 @@
+/*
+ * AMD Platform Security Processor (PSP) interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/ccp.h>
+
+#include "sp-dev.h"
+#include "psp-dev.h"
+
+const struct psp_vdata psp_entry = {
+ .offset = 0x10500,
+};
+
+static struct psp_device *psp_alloc_struct(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+
+ psp = devm_kzalloc(dev, sizeof(*psp), GFP_KERNEL);
+ if (!psp)
+ return NULL;
+
+ psp->dev = dev;
+ psp->sp = sp;
+
+ snprintf(psp->name, sizeof(psp->name), "psp-%u", sp->ord);
+
+ return psp;
+}
+
+static irqreturn_t psp_irq_handler(int irq, void *data)
+{
+ return IRQ_HANDLED;
+}
+
+int psp_dev_init(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+ int ret;
+
+ ret = -ENOMEM;
+ psp = psp_alloc_struct(sp);
+ if (!psp)
+ goto e_err;
+
+ sp->psp_data = psp;
+
+ psp->vdata = (struct psp_vdata *)sp->dev_vdata->psp_vdata;
+ if (!psp->vdata) {
+ ret = -ENODEV;
+ dev_err(dev, "missing driver data\n");
+ goto e_err;
+ }
+
+ psp->io_regs = sp->io_map + psp->vdata->offset;
+
+ /* Disable and clear interrupts until ready */
+ iowrite32(0, psp->io_regs + PSP_P2CMSG_INTEN);
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ dev_dbg(dev, "requesting an IRQ ...\n");
+ /* Request an irq */
+ ret = sp_request_psp_irq(psp->sp, psp_irq_handler, psp->name, psp);
+ if (ret) {
+ dev_err(dev, "psp: unable to allocate an IRQ\n");
+ goto e_err;
+ }
+
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
+ /* Enable interrupt */
+ dev_dbg(dev, "Enabling interrupts ...\n");
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
+
+ dev_notice(dev, "psp enabled\n");
+
+ return 0;
+
+e_err:
+ sp->psp_data = NULL;
+
+ dev_notice(dev, "psp initialization failed\n");
+
+ return ret;
+}
+
+void psp_dev_destroy(struct sp_device *sp)
+{
+ struct psp_device *psp = sp->psp_data;
+
+ sp_free_psp_irq(sp, psp);
+}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
new file mode 100644
index 000000000000..d53970ef5960
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -0,0 +1,61 @@
+/*
+ * AMD Platform Security Processor (PSP) interface driver
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_DEV_H__
+#define __PSP_DEV_H__
+
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/spinlock.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/wait.h>
+#include <linux/dmapool.h>
+#include <linux/hw_random.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/dmaengine.h>
+
+#include "sp-dev.h"
+
+#define PSP_P2CMSG_INTEN 0x0110
+#define PSP_P2CMSG_INTSTS 0x0114
+
+#define PSP_C2PMSG_ATTR_0 0x0118
+#define PSP_C2PMSG_ATTR_1 0x011c
+#define PSP_C2PMSG_ATTR_2 0x0120
+#define PSP_C2PMSG_ATTR_3 0x0124
+#define PSP_P2CMSG_ATTR_0 0x0128
+
+#define PSP_CMDRESP_CMD_SHIFT 16
+#define PSP_CMDRESP_IOC BIT(0)
+#define PSP_CMDRESP_RESP BIT(31)
+#define PSP_CMDRESP_ERR_MASK 0xffff
+
+#define MAX_PSP_NAME_LEN 16
+
+struct psp_device {
+ struct list_head entry;
+
+ struct psp_vdata *vdata;
+ char name[MAX_PSP_NAME_LEN];
+
+ struct device *dev;
+ struct sp_device *sp;
+
+ void __iomem *io_regs;
+};
+
+extern const struct psp_vdata psp_entry;
+
+#endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index bef387c8abfd..cf101c039c8f 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -198,6 +198,8 @@ int sp_init(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_init(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_init(sp);
return 0;
}
@@ -206,6 +208,9 @@ void sp_destroy(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_destroy(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_destroy(sp);
+
sp_del_device(sp);
}
@@ -237,6 +242,27 @@ int sp_resume(struct sp_device *sp)
}
#endif
+struct sp_device *sp_get_psp_master_device(void)
+{
+ struct sp_device *i, *ret = NULL;
+ unsigned long flags;
+
+ write_lock_irqsave(&sp_unit_lock, flags);
+ if (list_empty(&sp_units))
+ goto unlock;
+
+ list_for_each_entry(i, &sp_units, entry) {
+ if (i->psp_data)
+ break;
+ }
+
+ if (i->get_psp_master_device)
+ ret = i->get_psp_master_device();
+unlock:
+ write_unlock_irqrestore(&sp_unit_lock, flags);
+ return ret;
+}
+
static int __init sp_mod_init(void)
{
#ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 5ab486ade1ad..761dba176168 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,19 @@ struct ccp_vdata {
const unsigned int offset;
const unsigned int rsamax;
};
+
+struct psp_vdata {
+ const unsigned int version;
+ const struct psp_actions *perform;
+ const unsigned int offset;
+};
+
/* Structure to hold SP device data */
struct sp_dev_vdata {
const unsigned int bar;
const struct ccp_vdata *ccp_vdata;
- void *psp_vdata;
+ const struct psp_vdata *psp_vdata;
};
struct sp_device {
@@ -68,6 +75,10 @@ struct sp_device {
/* DMA caching attribute support */
unsigned int axcache;
+ /* get and set master device */
+ struct sp_device*(*get_psp_master_device)(void);
+ void (*set_psp_master_device)(struct sp_device *);
+
bool irq_registered;
bool use_tasklet;
@@ -103,6 +114,7 @@ void sp_free_ccp_irq(struct sp_device *sp, void *data);
int sp_request_psp_irq(struct sp_device *sp, irq_handler_t handler,
const char *name, void *data);
void sp_free_psp_irq(struct sp_device *sp, void *data);
+struct sp_device *sp_get_psp_master_device(void);
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
@@ -130,4 +142,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
}
#endif /* CONFIG_CRYPTO_DEV_SP_CCP */
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+
+int psp_dev_init(struct sp_device *sp);
+void psp_dev_destroy(struct sp_device *sp);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_dev_destroy(struct sp_device *sp) { }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 9859aa683a28..20a0f3543cf4 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -25,6 +25,7 @@
#include <linux/ccp.h>
#include "ccp-dev.h"
+#include "psp-dev.h"
#define MSIX_VECTORS 2
@@ -32,6 +33,7 @@ struct sp_pci {
int msix_count;
struct msix_entry msix_entry[MSIX_VECTORS];
};
+static struct sp_device *sp_dev_master;
static int sp_get_msix_irqs(struct sp_device *sp)
{
@@ -108,6 +110,45 @@ static void sp_free_irqs(struct sp_device *sp)
sp->psp_irq = 0;
}
+static bool sp_pci_is_master(struct sp_device *sp)
+{
+ struct device *dev_cur, *dev_new;
+ struct pci_dev *pdev_cur, *pdev_new;
+
+ dev_new = sp->dev;
+ dev_cur = sp_dev_master->dev;
+
+ pdev_new = to_pci_dev(dev_new);
+ pdev_cur = to_pci_dev(dev_cur);
+
+ if (pdev_new->bus->number < pdev_cur->bus->number)
+ return true;
+
+ if (PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn))
+ return true;
+
+ if (PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn))
+ return true;
+
+ return false;
+}
+
+static void psp_set_master(struct sp_device *sp)
+{
+ if (!sp_dev_master) {
+ sp_dev_master = sp;
+ return;
+ }
+
+ if (sp_pci_is_master(sp))
+ sp_dev_master = sp;
+}
+
+static struct sp_device *psp_get_master(void)
+{
+ return sp_dev_master;
+}
+
static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct sp_device *sp;
@@ -166,6 +207,8 @@ static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto e_err;
pci_set_master(pdev);
+ sp->set_psp_master_device = psp_set_master;
+ sp->get_psp_master_device = psp_get_master;
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48));
if (ret) {
@@ -237,6 +280,9 @@ static const struct sp_dev_vdata dev_vdata[] = {
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
.ccp_vdata = &ccpv5a,
#endif
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+ .psp_vdata = &psp_entry
+#endif
},
{
.bar = 2,
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-09-29 16:23 ` [Part2 PATCH v4.1 05/30] " Brijesh Singh
@ 2017-09-30 8:30 ` Borislav Petkov
2017-09-30 14:06 ` Brijesh Singh
0 siblings, 1 reply; 56+ messages in thread
From: Borislav Petkov @ 2017-09-30 8:30 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
Hi,
just a small Kconfig correction. Feel free to add it to your patchset.
Thx.
---
From: Borislav Petkov <bp@suse.de>
This is AMD-specific hardware so present it in Kconfig only when AMD
CPU support is enabled.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
---
drivers/crypto/ccp/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 627f3e61dcac..f58a6521270b 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,5 +1,6 @@
config CRYPTO_DEV_CCP_DD
tristate "Secure Processor device driver"
+ depends on CPU_SUP_AMD
default m
help
Provides AMD Secure Processor device driver.
--
2.13.0
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-09-30 8:30 ` [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Borislav Petkov
@ 2017-09-30 14:06 ` Brijesh Singh
2017-09-30 15:53 ` Borislav Petkov
0 siblings, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-09-30 14:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On 9/30/17 3:30 AM, Borislav Petkov wrote:
...
> From: Borislav Petkov <bp@suse.de>
>
> This is AMD-specific hardware so present it in Kconfig only when AMD
> CPU support is enabled.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Gary Hook <gary.hook@amd.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org
> ---
> drivers/crypto/ccp/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> index 627f3e61dcac..f58a6521270b 100644
> --- a/drivers/crypto/ccp/Kconfig
> +++ b/drivers/crypto/ccp/Kconfig
> @@ -1,5 +1,6 @@
> config CRYPTO_DEV_CCP_DD
> tristate "Secure Processor device driver"
> + depends on CPU_SUP_AMD
Please note that ccp.ko is built on both x86 and aarch64 (AMD Seattle)
architectures. I have not looked into details but I thought CPU_SUP_AMD
is x64 specific config. I will look into it and verify that we don't
break AMD Seattle platform builds.
> default m
> help
> Provides AMD Secure Processor device driver.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-09-30 14:06 ` Brijesh Singh
@ 2017-09-30 15:53 ` Borislav Petkov
0 siblings, 0 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-09-30 15:53 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Sat, Sep 30, 2017 at 09:06:26AM -0500, Brijesh Singh wrote:
> > diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> > index 627f3e61dcac..f58a6521270b 100644
> > --- a/drivers/crypto/ccp/Kconfig
> > +++ b/drivers/crypto/ccp/Kconfig
> > @@ -1,5 +1,6 @@
> > config CRYPTO_DEV_CCP_DD
> > tristate "Secure Processor device driver"
> > + depends on CPU_SUP_AMD
>
> Please note that ccp.ko is built on both x86 and aarch64 (AMD Seattle)
> architectures. I have not looked into details but I thought CPU_SUP_AMD
> is x64 specific config. I will look into it and verify that we don't
> break AMD Seattle platform builds.
Ah, then I guess that line needs to be:
depends on CPU_SUP_AMD || ARM64
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-29 15:16 ` Borislav Petkov
2017-09-29 16:23 ` [Part2 PATCH v4.1 05/30] " Brijesh Singh
@ 2017-09-30 15:55 ` Brijesh Singh
2017-09-30 16:11 ` Borislav Petkov
1 sibling, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-09-30 15:55 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, linux-kernel, kvm, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 9/29/17 10:16 AM, Borislav Petkov wrote:
...
> +
>> +config CRYPTO_DEV_SP_PSP
>> + bool "Platform Security Processor (PSP) device"
>> + default y
>> + depends on CRYPTO_DEV_CCP_DD
> So this last symbol CRYPTO_DEV_CCP_DD is default m and it doesn't depend
> on anything. And I'm pretty sure it should depend on CPU_SUP_AMD as this
> is AMD-specific hw. You can add that dependency in a prepatch.
CRYPTO_DEV_CCP_DD is supported on aarch64 and x86. Whereas the PSP
interface I am adding is available on x86 only hence its safe to add add
depend on CPU_SUP_AMD for CRYPTO_DEV_SP_PSP.
> And what happened to adding dependencies on CONFIG_KVM_AMD? Or can you
> use the PSP without virtualization in any sensible way?
Yes its very much possible. The SEV FW provides two sets of commands 1)
platform certificate management and 2) guest management
The platform certificate management commands is used outside the
CONFIG_KVM_AMD.
-Brijesh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-30 15:55 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-09-30 16:11 ` Borislav Petkov
2017-10-01 20:05 ` Brijesh Singh
0 siblings, 1 reply; 56+ messages in thread
From: Borislav Petkov @ 2017-09-30 16:11 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Sat, Sep 30, 2017 at 10:55:25AM -0500, Brijesh Singh wrote:
> CRYPTO_DEV_CCP_DD is supported on aarch64 and x86. Whereas the PSP
> interface I am adding is available on x86 only hence its safe to add add
> depend on CPU_SUP_AMD for CRYPTO_DEV_SP_PSP.
I think just from having CRYPTO_DEV_CCP_DD depend on CPU_SUP_AMD ||
ARM64, CRYPTO_DEV_SP_PSP gets almost the same dependency transitively.
But sure, let's make the PSP build only on x86. It should depend on
X86_64, to be precise.
> Yes its very much possible. The SEV FW provides two sets of commands 1)
> platform certificate management and 2) guest management
>
> The platform certificate management commands is used outside the
> CONFIG_KVM_AMD.
Ok, please state that in the commit message so that it is written down
somewhere.
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-30 16:11 ` Borislav Petkov
@ 2017-10-01 20:05 ` Brijesh Singh
2017-10-03 16:17 ` Borislav Petkov
0 siblings, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-10-01 20:05 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, linux-kernel, kvm, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 9/30/17 11:11 AM, Borislav Petkov wrote:
> I think just from having CRYPTO_DEV_CCP_DD depend on CPU_SUP_AMD ||
> ARM64, CRYPTO_DEV_SP_PSP gets almost the same dependency transitively.
> But sure, let's make the PSP build only on x86. It should depend on
> X86_64, to be precise.
I think theoretically a 32-bit host OS can invoke a PSP commands but
currently PSP interface is exposing only the SEV FW command. And SEV
feature is available when we are in 64-bit mode hence for now its okay
to have depends on X86_64. I will add CRYPTO_DEV_CCP_DD depend on
CPU_SUP_AMD || ARM64 and CRYPTO_DEV_SP_PSP depend on X86_64 and send you
v4.2. thanks
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-01 20:05 ` Brijesh Singh
@ 2017-10-03 16:17 ` Borislav Petkov
2017-10-03 16:19 ` Brijesh Singh
0 siblings, 1 reply; 56+ messages in thread
From: Borislav Petkov @ 2017-10-03 16:17 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-kernel, kvm, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Sun, Oct 01, 2017 at 03:05:11PM -0500, Brijesh Singh wrote:
> I think theoretically a 32-bit host OS can invoke a PSP commands but
> currently PSP interface is exposing only the SEV FW command. And SEV
Let's cross that bridge when we get to it.
> feature is available when we are in 64-bit mode hence for now its okay
> to have depends on X86_64. I will add CRYPTO_DEV_CCP_DD depend on
> CPU_SUP_AMD || ARM64 and CRYPTO_DEV_SP_PSP depend on X86_64 and send you
> v4.2.
No, please add my patch below to your set for the CRYPTO_DEV_CCP_DD
dependency as it is a separate thing. Your patch should concentrate only
on adding the PSP and its dependencies.
Thx.
---
From: Borislav Petkov <bp@suse.de>
Date: Sat, 30 Sep 2017 10:06:27 +0200
Subject: [PATCH] crypto: ccp: Build the AMD secure processor driver only with
AMD CPU support
This is AMD-specific hardware so present it in Kconfig only when AMD
CPU support is enabled or on ARM64 where it is also used.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
---
drivers/crypto/ccp/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 627f3e61dcac..f19f57162225 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,5 +1,6 @@
config CRYPTO_DEV_CCP_DD
tristate "Secure Processor device driver"
+ depends on CPU_SUP_AMD || ARM64
default m
help
Provides AMD Secure Processor device driver.
--
2.13.0
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-03 16:17 ` Borislav Petkov
@ 2017-10-03 16:19 ` Brijesh Singh
0 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-10-03 16:19 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, linux-kernel, kvm, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 10/03/2017 11:17 AM, Borislav Petkov wrote:
...
>
> No, please add my patch below to your set for the CRYPTO_DEV_CCP_DD
> dependency as it is a separate thing. Your patch should concentrate only
> on adding the PSP and its dependencies.
>
Sure, I will include your patch in my series. thanks
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Sat, 30 Sep 2017 10:06:27 +0200
> Subject: [PATCH] crypto: ccp: Build the AMD secure processor driver only with
> AMD CPU support
>
> This is AMD-specific hardware so present it in Kconfig only when AMD
> CPU support is enabled or on ARM64 where it is also used.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Gary Hook <gary.hook@amd.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org
> ---
> drivers/crypto/ccp/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> index 627f3e61dcac..f19f57162225 100644
> --- a/drivers/crypto/ccp/Kconfig
> +++ b/drivers/crypto/ccp/Kconfig
> @@ -1,5 +1,6 @@
> config CRYPTO_DEV_CCP_DD
> tristate "Secure Processor device driver"
> + depends on CPU_SUP_AMD || ARM64
> default m
> help
> Provides AMD Secure Processor device driver.
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 Patch v4.2] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-09-19 20:46 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-09-29 15:16 ` Borislav Petkov
@ 2017-10-02 16:43 ` Brijesh Singh
2017-10-04 6:36 ` P J P
1 sibling, 1 reply; 56+ messages in thread
From: Brijesh Singh @ 2017-10-02 16:43 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The Platform Security Processor (PSP) is part of AMD Secure Processor
(AMD-SP), PSP is a dedicated processor that provides the support for
key management commands in a Secure Encrypted Virtualization (SEV) mode,
along with software-based Trusted Execution Environment (TEE) to enable
the third-party trusted applications.
Note that the key management functionality provided by the SEV firmware
can be used outside the kvm-amd driver hence we don't do depends on
CONFIG_KVM_AMD.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Changes since v4.1:
* Add CPU_SUP_AMD depends
* Add a note in commit message that PSP can be used outside KVM
* Fix the Kconfig help based on Boris feedback
* Remove some superfluous debug statement
drivers/crypto/ccp/Kconfig | 12 +++++
drivers/crypto/ccp/Makefile | 1 +
drivers/crypto/ccp/psp-dev.c | 109 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 61 ++++++++++++++++++++++++
drivers/crypto/ccp/sp-dev.c | 26 +++++++++++
drivers/crypto/ccp/sp-dev.h | 26 ++++++++++-
drivers/crypto/ccp/sp-pci.c | 46 ++++++++++++++++++
7 files changed, 280 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccp/psp-dev.c
create mode 100644 drivers/crypto/ccp/psp-dev.h
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 6d626606b9c5..91177a5f1d32 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,6 +1,7 @@
config CRYPTO_DEV_CCP_DD
tristate "Secure Processor device driver"
default m
+ depends on CPU_SUP_AMD || ARM64
help
Provides AMD Secure Processor device driver.
If you choose 'M' here, this module will be called ccp.
@@ -32,3 +33,14 @@ config CRYPTO_DEV_CCP_CRYPTO
Support for using the cryptographic API with the AMD Cryptographic
Coprocessor. This module supports offload of SHA and AES algorithms.
If you choose 'M' here, this module will be called ccp_crypto.
+
+config CRYPTO_DEV_SP_PSP
+ bool "Platform Security Processor (PSP) device"
+ default y
+ depends on CRYPTO_DEV_CCP_DD && X86_64
+ help
+ Provide the support for the AMD Platform Security Processor (PSP).
+ The PSP is a dedicated processor that provides support for key
+ management commands in Secure Encrypted Virtualization (SEV) mode,
+ along with software-based Trusted Execution Environment (TEE) to
+ enable the third-party trusted applications.
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 57f8debfcfb3..008bae7e26ec 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -7,6 +7,7 @@ ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
ccp-dmaengine.o \
ccp-debugfs.o
ccp-$(CONFIG_PCI) += sp-pci.o
+ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o
obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
new file mode 100644
index 000000000000..7480d4316239
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -0,0 +1,109 @@
+/*
+ * AMD Platform Security Processor (PSP) interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/ccp.h>
+
+#include "sp-dev.h"
+#include "psp-dev.h"
+
+const struct psp_vdata psp_entry = {
+ .offset = 0x10500,
+};
+
+static struct psp_device *psp_alloc_struct(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+
+ psp = devm_kzalloc(dev, sizeof(*psp), GFP_KERNEL);
+ if (!psp)
+ return NULL;
+
+ psp->dev = dev;
+ psp->sp = sp;
+
+ snprintf(psp->name, sizeof(psp->name), "psp-%u", sp->ord);
+
+ return psp;
+}
+
+static irqreturn_t psp_irq_handler(int irq, void *data)
+{
+ return IRQ_HANDLED;
+}
+
+int psp_dev_init(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+ int ret;
+
+ ret = -ENOMEM;
+ psp = psp_alloc_struct(sp);
+ if (!psp)
+ goto e_err;
+
+ sp->psp_data = psp;
+
+ psp->vdata = (struct psp_vdata *)sp->dev_vdata->psp_vdata;
+ if (!psp->vdata) {
+ ret = -ENODEV;
+ dev_err(dev, "missing driver data\n");
+ goto e_err;
+ }
+
+ psp->io_regs = sp->io_map + psp->vdata->offset;
+
+ /* Disable and clear interrupts until ready */
+ iowrite32(0, psp->io_regs + PSP_P2CMSG_INTEN);
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ /* Request an irq */
+ ret = sp_request_psp_irq(psp->sp, psp_irq_handler, psp->name, psp);
+ if (ret) {
+ dev_err(dev, "psp: unable to allocate an IRQ\n");
+ goto e_err;
+ }
+
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
+ /* Enable interrupt */
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
+
+ return 0;
+
+e_err:
+ sp->psp_data = NULL;
+
+ dev_notice(dev, "psp initialization failed\n");
+
+ return ret;
+}
+
+void psp_dev_destroy(struct sp_device *sp)
+{
+ struct psp_device *psp = sp->psp_data;
+
+ sp_free_psp_irq(sp, psp);
+}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
new file mode 100644
index 000000000000..d53970ef5960
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -0,0 +1,61 @@
+/*
+ * AMD Platform Security Processor (PSP) interface driver
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_DEV_H__
+#define __PSP_DEV_H__
+
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/spinlock.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/wait.h>
+#include <linux/dmapool.h>
+#include <linux/hw_random.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/dmaengine.h>
+
+#include "sp-dev.h"
+
+#define PSP_P2CMSG_INTEN 0x0110
+#define PSP_P2CMSG_INTSTS 0x0114
+
+#define PSP_C2PMSG_ATTR_0 0x0118
+#define PSP_C2PMSG_ATTR_1 0x011c
+#define PSP_C2PMSG_ATTR_2 0x0120
+#define PSP_C2PMSG_ATTR_3 0x0124
+#define PSP_P2CMSG_ATTR_0 0x0128
+
+#define PSP_CMDRESP_CMD_SHIFT 16
+#define PSP_CMDRESP_IOC BIT(0)
+#define PSP_CMDRESP_RESP BIT(31)
+#define PSP_CMDRESP_ERR_MASK 0xffff
+
+#define MAX_PSP_NAME_LEN 16
+
+struct psp_device {
+ struct list_head entry;
+
+ struct psp_vdata *vdata;
+ char name[MAX_PSP_NAME_LEN];
+
+ struct device *dev;
+ struct sp_device *sp;
+
+ void __iomem *io_regs;
+};
+
+extern const struct psp_vdata psp_entry;
+
+#endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index bef387c8abfd..cf101c039c8f 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -198,6 +198,8 @@ int sp_init(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_init(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_init(sp);
return 0;
}
@@ -206,6 +208,9 @@ void sp_destroy(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_destroy(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_destroy(sp);
+
sp_del_device(sp);
}
@@ -237,6 +242,27 @@ int sp_resume(struct sp_device *sp)
}
#endif
+struct sp_device *sp_get_psp_master_device(void)
+{
+ struct sp_device *i, *ret = NULL;
+ unsigned long flags;
+
+ write_lock_irqsave(&sp_unit_lock, flags);
+ if (list_empty(&sp_units))
+ goto unlock;
+
+ list_for_each_entry(i, &sp_units, entry) {
+ if (i->psp_data)
+ break;
+ }
+
+ if (i->get_psp_master_device)
+ ret = i->get_psp_master_device();
+unlock:
+ write_unlock_irqrestore(&sp_unit_lock, flags);
+ return ret;
+}
+
static int __init sp_mod_init(void)
{
#ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 5ab486ade1ad..761dba176168 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,19 @@ struct ccp_vdata {
const unsigned int offset;
const unsigned int rsamax;
};
+
+struct psp_vdata {
+ const unsigned int version;
+ const struct psp_actions *perform;
+ const unsigned int offset;
+};
+
/* Structure to hold SP device data */
struct sp_dev_vdata {
const unsigned int bar;
const struct ccp_vdata *ccp_vdata;
- void *psp_vdata;
+ const struct psp_vdata *psp_vdata;
};
struct sp_device {
@@ -68,6 +75,10 @@ struct sp_device {
/* DMA caching attribute support */
unsigned int axcache;
+ /* get and set master device */
+ struct sp_device*(*get_psp_master_device)(void);
+ void (*set_psp_master_device)(struct sp_device *);
+
bool irq_registered;
bool use_tasklet;
@@ -103,6 +114,7 @@ void sp_free_ccp_irq(struct sp_device *sp, void *data);
int sp_request_psp_irq(struct sp_device *sp, irq_handler_t handler,
const char *name, void *data);
void sp_free_psp_irq(struct sp_device *sp, void *data);
+struct sp_device *sp_get_psp_master_device(void);
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
@@ -130,4 +142,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
}
#endif /* CONFIG_CRYPTO_DEV_SP_CCP */
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+
+int psp_dev_init(struct sp_device *sp);
+void psp_dev_destroy(struct sp_device *sp);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_dev_destroy(struct sp_device *sp) { }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 9859aa683a28..20a0f3543cf4 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -25,6 +25,7 @@
#include <linux/ccp.h>
#include "ccp-dev.h"
+#include "psp-dev.h"
#define MSIX_VECTORS 2
@@ -32,6 +33,7 @@ struct sp_pci {
int msix_count;
struct msix_entry msix_entry[MSIX_VECTORS];
};
+static struct sp_device *sp_dev_master;
static int sp_get_msix_irqs(struct sp_device *sp)
{
@@ -108,6 +110,45 @@ static void sp_free_irqs(struct sp_device *sp)
sp->psp_irq = 0;
}
+static bool sp_pci_is_master(struct sp_device *sp)
+{
+ struct device *dev_cur, *dev_new;
+ struct pci_dev *pdev_cur, *pdev_new;
+
+ dev_new = sp->dev;
+ dev_cur = sp_dev_master->dev;
+
+ pdev_new = to_pci_dev(dev_new);
+ pdev_cur = to_pci_dev(dev_cur);
+
+ if (pdev_new->bus->number < pdev_cur->bus->number)
+ return true;
+
+ if (PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn))
+ return true;
+
+ if (PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn))
+ return true;
+
+ return false;
+}
+
+static void psp_set_master(struct sp_device *sp)
+{
+ if (!sp_dev_master) {
+ sp_dev_master = sp;
+ return;
+ }
+
+ if (sp_pci_is_master(sp))
+ sp_dev_master = sp;
+}
+
+static struct sp_device *psp_get_master(void)
+{
+ return sp_dev_master;
+}
+
static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct sp_device *sp;
@@ -166,6 +207,8 @@ static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto e_err;
pci_set_master(pdev);
+ sp->set_psp_master_device = psp_set_master;
+ sp->get_psp_master_device = psp_get_master;
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48));
if (ret) {
@@ -237,6 +280,9 @@ static const struct sp_dev_vdata dev_vdata[] = {
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
.ccp_vdata = &ccpv5a,
#endif
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+ .psp_vdata = &psp_entry
+#endif
},
{
.bar = 2,
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 Patch v4.2] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-02 16:43 ` [Part2 Patch v4.2] " Brijesh Singh
@ 2017-10-04 6:36 ` P J P
2017-10-04 9:15 ` Borislav Petkov
0 siblings, 1 reply; 56+ messages in thread
From: P J P @ 2017-10-04 6:36 UTC (permalink / raw)
To: Brijesh Singh
Cc: bp, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
+-- On Mon, 2 Oct 2017, Brijesh Singh wrote --+
| +int psp_dev_init(struct sp_device *sp)
| +{
| + struct device *dev = sp->dev;
| + struct psp_device *psp;
| + int ret;
| +
| + ret = -ENOMEM;
| + psp = psp_alloc_struct(sp);
| + if (!psp)
| + goto e_err;
| +
| + sp->psp_data = psp;
| ...
| +e_err:
| + sp->psp_data = NULL;
Needs to kfree(sp->psp_data) before setting to NULL.
--
- P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 Patch v4.2] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-04 6:36 ` P J P
@ 2017-10-04 9:15 ` Borislav Petkov
0 siblings, 0 replies; 56+ messages in thread
From: Borislav Petkov @ 2017-10-04 9:15 UTC (permalink / raw)
To: P J P
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 04, 2017 at 12:06:42PM +0530, P J P wrote:
> Needs to kfree(sp->psp_data) before setting to NULL.
Not if it is allocated with devm_kzalloc().
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 PATCH v4 06/29] ccp: crypto: Define SEV key management command id
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (4 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 05/29] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
` (22 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/linux/psp-sev.h | 512 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 512 insertions(+)
create mode 100644 include/linux/psp-sev.h
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
new file mode 100644
index 000000000000..d40709b65b18
--- /dev/null
+++ b/include/linux/psp-sev.h
@@ -0,0 +1,512 @@
+/*
+ * AMD Secure Encrypted Virtualization (SEV) driver interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_SEV_H__
+#define __PSP_SEV_H__
+
+#ifdef CONFIG_X86
+#include <linux/mem_encrypt.h>
+
+#define __psp_pa(x) __sme_pa(x)
+#else
+#define __psp_pa(x) __pa(x)
+#endif
+
+#define SEV_FW_BLOB_MAX_SIZE 0x4000 /* 16KB */
+
+/**
+ * SEV platform state
+ */
+enum sev_state {
+ SEV_STATE_UNINIT = 0x0,
+ SEV_STATE_INIT = 0x1,
+ SEV_STATE_WORKING = 0x2,
+
+ SEV_STATE_MAX
+};
+
+/**
+ * SEV platform and guest management commands
+ */
+enum sev_cmd {
+ /* platform commands */
+ SEV_CMD_INIT = 0x001,
+ SEV_CMD_SHUTDOWN = 0x002,
+ SEV_CMD_FACTORY_RESET = 0x003,
+ SEV_CMD_PLATFORM_STATUS = 0x004,
+ SEV_CMD_PEK_GEN = 0x005,
+ SEV_CMD_PEK_CSR = 0x006,
+ SEV_CMD_PEK_CERT_IMPORT = 0x007,
+ SEV_CMD_PDH_CERT_EXPORT = 0x008,
+ SEV_CMD_PDH_GEN = 0x009,
+ SEV_CMD_DF_FLUSH = 0x00A,
+
+ /* Guest commands */
+ SEV_CMD_DECOMMISSION = 0x020,
+ SEV_CMD_ACTIVATE = 0x021,
+ SEV_CMD_DEACTIVATE = 0x022,
+ SEV_CMD_GUEST_STATUS = 0x023,
+
+ /* Guest launch commands */
+ SEV_CMD_LAUNCH_START = 0x030,
+ SEV_CMD_LAUNCH_UPDATE_DATA = 0x031,
+ SEV_CMD_LAUNCH_UPDATE_VMSA = 0x032,
+ SEV_CMD_LAUNCH_MEASURE = 0x033,
+ SEV_CMD_LAUNCH_UPDATE_SECRET = 0x034,
+ SEV_CMD_LAUNCH_FINISH = 0x035,
+
+ /* Guest migration commands (outgoing) */
+ SEV_CMD_SEND_START = 0x040,
+ SEV_CMD_SEND_UPDATE_DATA = 0x041,
+ SEV_CMD_SEND_UPDATE_VMSA = 0x042,
+ SEV_CMD_SEND_FINISH = 0x043,
+
+ /* Guest migration commands (incoming) */
+ SEV_CMD_RECEIVE_START = 0x050,
+ SEV_CMD_RECEIVE_UPDATE_DATA = 0x051,
+ SEV_CMD_RECEIVE_UPDATE_VMSA = 0x052,
+ SEV_CMD_RECEIVE_FINISH = 0x053,
+
+ /* Guest debug commands */
+ SEV_CMD_DBG_DECRYPT = 0x060,
+ SEV_CMD_DBG_ENCRYPT = 0x061,
+
+ SEV_CMD_MAX,
+};
+
+/**
+ * status code returned by the commands
+ */
+enum psp_ret_code {
+ SEV_RET_SUCCESS = 0,
+ SEV_RET_INVALID_PLATFORM_STATE,
+ SEV_RET_INVALID_GUEST_STATE,
+ SEV_RET_INAVLID_CONFIG,
+ SEV_RET_INVALID_len,
+ SEV_RET_ALREADY_OWNED,
+ SEV_RET_INVALID_CERTIFICATE,
+ SEV_RET_POLICY_FAILURE,
+ SEV_RET_INACTIVE,
+ SEV_RET_INVALID_ADDRESS,
+ SEV_RET_BAD_SIGNATURE,
+ SEV_RET_BAD_MEASUREMENT,
+ SEV_RET_ASID_OWNED,
+ SEV_RET_INVALID_ASID,
+ SEV_RET_WBINVD_REQUIRED,
+ SEV_RET_DFFLUSH_REQUIRED,
+ SEV_RET_INVALID_GUEST,
+ SEV_RET_INVALID_COMMAND,
+ SEV_RET_ACTIVE,
+ SEV_RET_HWSEV_RET_PLATFORM,
+ SEV_RET_HWSEV_RET_UNSAFE,
+ SEV_RET_UNSUPPORTED,
+ SEV_RET_MAX,
+};
+
+/**
+ * struct sev_data_init - INIT command parameters
+ *
+ * @flags: processing flags
+ * @tmr_address: system physical address used for SEV-ES
+ * @tmr_len: len of tmr_address
+ */
+struct __attribute__((__packed__)) sev_data_init {
+ u32 flags; /* In */
+ u32 reserved; /* In */
+ u64 tmr_address; /* In */
+ u32 tmr_len; /* In */
+};
+
+/**
+ * struct sev_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct __attribute__((__packed__)) sev_data_status {
+ u8 api_major; /* Out */
+ u8 api_minor; /* Out */
+ u8 state; /* Out */
+ u8 owner : 1; /* Out */
+ u8 reserved1 : 7;
+ u32 config : 1; /* Out */
+ u32 reserved2 : 23;
+ u32 build : 8; /* Out */
+ u32 guest_count; /* Out */
+};
+
+/**
+ * struct sev_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @len: len of certificate
+ */
+struct __attribute__((__packed__)) sev_data_pek_csr {
+ u64 address; /* In */
+ u32 len; /* In/Out */
+};
+
+/**
+ * struct sev_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: len of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: len of OCA certificate
+ */
+struct __attribute__((__packed__)) sev_data_pek_cert_import {
+ u64 pek_cert_address; /* In */
+ u32 pek_cert_len; /* In */
+ u32 reserved; /* In */
+ u64 oca_cert_address; /* In */
+ u32 oca_cert_len; /* In */
+};
+
+/**
+ * struct sev_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: len of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: len of PDH certificate chain
+ */
+struct __attribute__((__packed__)) sev_data_pdh_cert_export {
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In/Out */
+ u32 reserved; /* In */
+ u64 cert_chain_address; /* In */
+ u32 cert_chain_len; /* In/Out */
+};
+
+/**
+ * struct sev_data_decommission - DECOMMISSION command parameters
+ *
+ * @handle: handle of the VM to decommission
+ */
+struct __attribute__((__packed__)) sev_data_decommission {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_activate - ACTIVATE command parameters
+ *
+ * @handle: handle of the VM to activate
+ * @asid: asid assigned to the VM
+ */
+struct __attribute__((__packed__)) sev_data_activate {
+ u32 handle; /* In */
+ u32 asid; /* In */
+};
+
+/**
+ * struct sev_data_deactivate - DEACTIVATE command parameters
+ *
+ * @handle: handle of the VM to deactivate
+ */
+struct __attribute__((__packed__)) sev_data_deactivate {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_guest_status - SEV GUEST_STATUS command parameters
+ *
+ * @handle: handle of the VM to retrieve status
+ * @policy: policy information for the VM
+ * @asid: current ASID of the VM
+ * @state: current state of the VM
+ */
+struct __attribute__((__packed__)) sev_data_guest_status {
+ u32 handle; /* In */
+ u32 policy; /* Out */
+ u32 asid; /* Out */
+ u8 state; /* Out */
+};
+
+/**
+ * struct sev_data_launch_start - LAUNCH_START command parameters
+ *
+ * @handle: handle assigned to the VM
+ * @policy: guest launch policy
+ * @dh_cert_address: physical address of DH certificate blob
+ * @dh_cert_len: len of DH certificate blob
+ * @session_address: physical address of session parameters
+ * @session_len: len of session parameters
+ */
+struct __attribute__((__packed__)) sev_data_launch_start {
+ u32 handle; /* In/Out */
+ u32 policy; /* In */
+ u64 dh_cert_address; /* In */
+ u32 dh_cert_len; /* In */
+ u32 reserved; /* In */
+ u64 session_address; /* In */
+ u32 session_len; /* In */
+};
+
+/**
+ * struct sev_data_launch_update_data - LAUNCH_UPDATE_DATA command parameter
+ *
+ * @handle: handle of the VM to update
+ * @len: len of memory to be encrypted
+ * @address: physical address of memory region to encrypt
+ */
+struct __attribute__((__packed__)) sev_data_launch_update_data {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In */
+};
+
+/**
+ * struct sev_data_launch_update_vmsa - LAUNCH_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM
+ * @address: physical address of memory region to encrypt
+ * @len: len of memory region to encrypt
+ */
+struct __attribute__((__packed__)) sev_data_launch_update_vmsa {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In */
+};
+
+/**
+ * struct sev_data_launch_measure - LAUNCH_MEASURE command parameters
+ *
+ * @handle: handle of the VM to process
+ * @address: physical address containing the measurement blob
+ * @len: len of measurement blob
+ */
+struct __attribute__((__packed__)) sev_data_launch_measure {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In/Out */
+};
+
+/**
+ * struct sev_data_launch_secret - LAUNCH_SECRET command parameters
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing the packet header
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest_paddr
+ * @trans_address: physical address of transport memory buffer
+ * @trans_len: len of transport memory buffer
+ */
+struct __attribute__((__packed__)) sev_data_launch_secret {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_launch_finish - LAUNCH_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct __attribute__((__packed__)) sev_data_launch_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_send_start - SEND_START command parameters
+ *
+ * @handle: handle of the VM to process
+ * @policy: policy information for the VM
+ * @pdh_cert_address: physical address containing PDH certificate
+ * @pdh_cert_len: len of PDH certificate
+ * @plat_certs_address: physical address containing platform certificate
+ * @plat_certs_len: len of platform certificate
+ * @amd_certs_address: physical address containing AMD certificate
+ * @amd_certs_len: len of AMD certificate
+ * @session_address: physical address containing Session data
+ * @session_len: len of session data
+ */
+struct __attribute__((__packed__)) sev_data_send_start {
+ u32 handle; /* In */
+ u32 policy; /* Out */
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In */
+ u32 reserved1;
+ u64 plat_cert_address; /* In */
+ u32 plat_cert_len; /* In */
+ u32 reserved2;
+ u64 amd_cert_address; /* In */
+ u32 amd_cert_len; /* In */
+ u32 reserved3;
+ u64 session_address; /* In */
+ u32 session_len; /* In/Out */
+};
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_DATA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct __attribute__((__packed__)) sev_data_send_update_data {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In/Out */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct __attribute__((__packed__)) sev_data_send_update_vmsa {
+ u32 handle; /* In */
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In/Out */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_send_finish - SEND_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct __attribute__((__packed__)) sev_data_send_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_receive_start - RECEIVE_START command parameters
+ *
+ * @handle: handle of the VM to perform receive operation
+ * @pdh_cert_address: system physical address containing PDH certificate blob
+ * @pdh_cert_len: len of PDH certificate blob
+ * @session_address: system physical address containing session blob
+ * @session_len: len of session blob
+ */
+struct __attribute__((__packed__)) sev_data_receive_start {
+ u32 handle; /* In/Out */
+ u32 policy; /* In */
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In */
+ u32 reserved1;
+ u64 session_address; /* In */
+ u32 session_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_update_data - RECEIVE_UPDATE_DATA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct __attribute__((__packed__)) sev_data_receive_update_data {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_update_vmsa - RECEIVE_UPDATE_VMSA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct __attribute__((__packed__)) sev_data_receive_update_vmsa {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_finish - RECEIVE_FINISH command parameters
+ *
+ * @handle: handle of the VM to finish
+ */
+struct __attribute__((__packed__)) sev_data_receive_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_dbg - DBG_ENCRYPT/DBG_DECRYPT command parameters
+ *
+ * @handle: handle of the VM to perform debug operation
+ * @src_addr: source address of data to operate on
+ * @dst_addr: destination address of data to operate on
+ * @len: len of data to operate on
+ */
+struct __attribute__((__packed__)) sev_data_dbg {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 src_addr; /* In */
+ u64 dst_addr; /* In */
+ u32 len; /* In */
+};
+
+#endif /* __PSP_SEV_H__ */
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (5 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 06/29] ccp: crypto: Define SEV key management command id Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-22 21:35 ` [PATCH] crypto: ccp: fix eno.cocci warnings kbuild test robot
2017-09-22 21:35 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support kbuild test robot
2017-09-19 20:46 ` [Part2 PATCH v4 08/29] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
` (21 subsequent siblings)
28 siblings, 2 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory
contents of a virtual machines to be transparently encrypted with a key
unique to the guest VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP), which exposes the
commands for these tasks. The complete spec is available at:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
Extend the AMD-SP driver to provide the following support:
- an in-kernel APIs to communicate with a SEV firmware. The APIs can be
used by the hypervisor to create encryption context for the SEV guests.
- an userspace IOCTL to manage the platform certificates
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/psp-dev.c | 743 ++++++++++++++++++++++++++++++++++++++++++-
drivers/crypto/ccp/psp-dev.h | 17 +
include/linux/psp-sev.h | 171 ++++++++++
include/uapi/linux/psp-sev.h | 114 +++++++
4 files changed, 1044 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/linux/psp-sev.h
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e60e53272e71..c74e383666f8 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -23,9 +23,20 @@
#include <linux/hw_random.h>
#include <linux/ccp.h>
+#include <uapi/linux/psp-sev.h>
+
#include "sp-dev.h"
#include "psp-dev.h"
+#define DEVICE_NAME "sev"
+
+static unsigned int sev_poll;
+module_param(sev_poll, uint, 0444);
+MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
+
+DEFINE_MUTEX(sev_cmd_mutex);
+static bool sev_fops_registered;
+
const struct psp_vdata psp_entry = {
.offset = 0x10500,
};
@@ -49,9 +60,732 @@ static struct psp_device *psp_alloc_struct(struct sp_device *sp)
irqreturn_t psp_irq_handler(int irq, void *data)
{
+ unsigned int status;
+ struct psp_device *psp = data;
+
+ /* read the interrupt status */
+ status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ /* check if its command completion */
+ if (status & (1 << PSP_CMD_COMPLETE_REG)) {
+ int reg;
+
+ /* check if its SEV command completion */
+ reg = ioread32(psp->io_regs + PSP_CMDRESP);
+ if (reg & PSP_CMDRESP_RESP) {
+ psp->sev_int_rcvd = 1;
+ wake_up(&psp->sev_int_queue);
+ }
+ }
+
+ /* clear the interrupt status by writing 1 */
+ iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
+
return IRQ_HANDLED;
}
+static struct psp_device *psp_get_master_device(void)
+{
+ struct sp_device *sp = sp_get_psp_master_device();
+
+ return sp ? sp->psp_data : NULL;
+}
+
+static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
+ unsigned int *reg)
+{
+ int wait = timeout * 10; /* 100ms sleep => timeout * 10 */
+
+ while (--wait) {
+ msleep(100);
+
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+ if (*reg & PSP_CMDRESP_RESP)
+ break;
+ }
+
+ if (!wait) {
+ dev_err(psp->dev, "sev command timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
+{
+ psp->sev_int_rcvd = 0;
+
+ wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+
+ return 0;
+}
+
+static int sev_wait_cmd(struct psp_device *psp, unsigned int *reg)
+{
+ return (*reg & PSP_CMDRESP_IOC) ? sev_wait_cmd_ioc(psp, reg)
+ : sev_wait_cmd_poll(psp, 10, reg);
+}
+
+static int sev_cmd_buffer_len(int cmd)
+{
+ switch (cmd) {
+ case SEV_CMD_INIT:
+ return sizeof(struct sev_data_init);
+ case SEV_CMD_PLATFORM_STATUS:
+ return sizeof(struct sev_data_status);
+ case SEV_CMD_PEK_CSR:
+ return sizeof(struct sev_data_pek_csr);
+ case SEV_CMD_PEK_CERT_IMPORT:
+ return sizeof(struct sev_data_pek_cert_import);
+ case SEV_CMD_PDH_CERT_EXPORT:
+ return sizeof(struct sev_data_pdh_cert_export);
+ case SEV_CMD_LAUNCH_START:
+ return sizeof(struct sev_data_launch_start);
+ case SEV_CMD_LAUNCH_UPDATE_DATA:
+ return sizeof(struct sev_data_launch_update_data);
+ case SEV_CMD_LAUNCH_UPDATE_VMSA:
+ return sizeof(struct sev_data_launch_update_vmsa);
+ case SEV_CMD_LAUNCH_FINISH:
+ return sizeof(struct sev_data_launch_finish);
+ case SEV_CMD_LAUNCH_UPDATE_SECRET:
+ return sizeof(struct sev_data_launch_secret);
+ case SEV_CMD_LAUNCH_MEASURE:
+ return sizeof(struct sev_data_launch_measure);
+ case SEV_CMD_ACTIVATE:
+ return sizeof(struct sev_data_activate);
+ case SEV_CMD_DEACTIVATE:
+ return sizeof(struct sev_data_deactivate);
+ case SEV_CMD_DECOMMISSION:
+ return sizeof(struct sev_data_decommission);
+ case SEV_CMD_GUEST_STATUS:
+ return sizeof(struct sev_data_guest_status);
+ case SEV_CMD_DBG_DECRYPT:
+ case SEV_CMD_DBG_ENCRYPT:
+ return sizeof(struct sev_data_dbg);
+ case SEV_CMD_SEND_START:
+ return sizeof(struct sev_data_send_start);
+ case SEV_CMD_SEND_UPDATE_DATA:
+ return sizeof(struct sev_data_send_update_data);
+ case SEV_CMD_SEND_UPDATE_VMSA:
+ return sizeof(struct sev_data_send_update_vmsa);
+ case SEV_CMD_SEND_FINISH:
+ return sizeof(struct sev_data_send_finish);
+ case SEV_CMD_RECEIVE_START:
+ return sizeof(struct sev_data_receive_start);
+ case SEV_CMD_RECEIVE_UPDATE_DATA:
+ return sizeof(struct sev_data_receive_update_data);
+ case SEV_CMD_RECEIVE_UPDATE_VMSA:
+ return sizeof(struct sev_data_receive_update_vmsa);
+ case SEV_CMD_RECEIVE_FINISH:
+ return sizeof(struct sev_data_receive_finish);
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+
+static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
+{
+ struct psp_device *psp = psp_get_master_device();
+ unsigned int phys_lsb, phys_msb;
+ unsigned int reg, ret;
+
+ if (!psp)
+ return -ENODEV;
+
+ /* Set the physical address for the PSP */
+ phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0;
+ phys_msb = data ? upper_32_bits(__psp_pa(data)) : 0;
+
+ dev_dbg(psp->dev, "sev command id %#x buffer 0x%08x%08x\n",
+ cmd, phys_msb, phys_lsb);
+ print_hex_dump_debug("(in): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+ sev_cmd_buffer_len(cmd), false);
+
+ /* Only one command at a time... */
+ mutex_lock(&sev_cmd_mutex);
+
+ iowrite32(phys_lsb, psp->io_regs + PSP_CMDBUFF_ADDR_LO);
+ iowrite32(phys_msb, psp->io_regs + PSP_CMDBUFF_ADDR_HI);
+
+ reg = cmd;
+ reg <<= PSP_CMDRESP_CMD_SHIFT;
+ reg |= sev_poll ? 0 : PSP_CMDRESP_IOC;
+ iowrite32(reg, psp->io_regs + PSP_CMDRESP);
+
+ ret = sev_wait_cmd(psp, ®);
+ if (ret)
+ goto unlock;
+
+ if (psp_ret)
+ *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
+
+ if (reg & PSP_CMDRESP_ERR_MASK) {
+ dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
+ cmd, reg & PSP_CMDRESP_ERR_MASK);
+ ret = -EIO;
+ }
+
+unlock:
+ mutex_unlock(&sev_cmd_mutex);
+ print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+ sev_cmd_buffer_len(cmd), false);
+ return ret;
+}
+
+static int sev_platform_get_state(int *state, int *error)
+{
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+ if (!ret)
+ *state = data->state;
+
+ kfree(data);
+ return ret;
+}
+
+static int sev_firmware_init(int *error)
+{
+ struct sev_data_init *data;
+ int rc;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ rc = sev_handle_cmd(SEV_CMD_INIT, data, error);
+
+ kfree(data);
+ return rc;
+}
+
+static inline int sev_ioctl_factory_reset(struct sev_issue_cmd *argp)
+{
+ return sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &argp->error);
+}
+
+static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
+{
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
+ if (ret)
+ goto e_free;
+
+ if (copy_to_user((void __user *)(uintptr_t) argp->data,
+ data, sizeof(*data))) {
+ ret = -EFAULT;
+ goto e_free;
+ }
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static void *copy_user_blob(u64 __user uaddr, u32 len)
+{
+ void *data;
+
+ if (!uaddr || !len)
+ return ERR_PTR(-EINVAL);
+
+ /* verify that blob length does not exceed our limit */
+ if (len > SEV_FW_BLOB_MAX_SIZE)
+ return ERR_PTR(-EINVAL);
+
+ data = kmalloc(len, GFP_KERNEL);
+ if (IS_ERR(data))
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ goto e_free;
+
+ return data;
+e_free:
+ kfree(data);
+ return ERR_PTR(-EFAULT);
+}
+
+static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_csr input;
+ struct sev_data_pek_csr *data;
+ int do_shutdown = 0;
+ int ret, state;
+ void *blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pek_csr)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+
+ /* copy the PEK certificate blob from userspace */
+ blob = NULL;
+ if (input.address) {
+ blob = copy_user_blob(input.address, input.length);
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ goto e_free;
+ }
+
+ data->address = __psp_pa(blob);
+ data->len = input.length;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_blob;
+
+ /*
+ * PEK_CERT command can be issued only when we are in INIT state.
+ * if current state is WORKING then reject it, if state is UNINIT
+ * then transition the platform to INIT state before issuing the
+ * command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_blob;
+ } else if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_blob;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+ input.length = data->len;
+
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pek_csr)))
+ ret = -EFAULT;
+
+ /* transition the plaform into INIT state */
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
+{
+ int ret, state, do_shutdown = 0;
+
+ /*
+ * PDH_GEN command can be issued when platform is in INIT or WORKING
+ * state. If we are in UNINIT state then transition into INIT state
+ * before issuing the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_UNINIT) {
+ /* transition the plaform into INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
+static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
+{
+ int do_shutdown = 0;
+ int ret, state;
+
+ /*
+ * PEK_GEN command can be issued only when firmware is in INIT state.
+ * If firmware is in UNINIT state then we transition it into INIT state
+ * and issue the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_WORKING) {
+ return -EBUSY;
+ } else if (state == SEV_STATE_UNINIT) {
+ /* transition the plaform into INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
+static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_cert_import input;
+ struct sev_data_pek_cert_import *data;
+ int ret, state, do_shutdown = 0;
+ void *pek_blob, *oca_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t) argp->data,
+ sizeof(struct sev_user_data_pek_cert_import)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* copy PEK certificate blobs from userspace */
+ pek_blob = copy_user_blob(input.pek_cert_address, input.pek_cert_len);
+ if (IS_ERR(pek_blob)) {
+ ret = PTR_ERR(pek_blob);
+ goto e_free;
+ }
+
+ data->pek_cert_address = __psp_pa(pek_blob);
+ data->pek_cert_len = input.pek_cert_len;
+
+ /* copy PEK certificate blobs from userspace */
+ oca_blob = copy_user_blob(input.oca_cert_address, input.oca_cert_len);
+ if (IS_ERR(oca_blob)) {
+ ret = PTR_ERR(oca_blob);
+ goto e_free_pek;
+ }
+
+ data->oca_cert_address = __psp_pa(oca_blob);
+ data->oca_cert_len = input.oca_cert_len;
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_oca;
+
+ /*
+ * PEK_CERT_IMPORT command can be issued only when platform is in INIT
+ * state. If we are in UNINIT state then transition into INIT state
+ * before issuing the command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_oca;
+ } else if (state == SEV_STATE_UNINIT) {
+ /* transition platform init INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_oca;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+e_free_oca:
+ kfree(oca_blob);
+e_free_pek:
+ kfree(pek_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pdh_cert_export input;
+ struct sev_data_pdh_cert_export *data;
+ int ret, state, need_shutdown = 0;
+ void *pdh_blob, *cert_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ pdh_blob = NULL;
+ if (input.pdh_cert_address) {
+ if (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free;
+ }
+
+ pdh_blob = kmalloc(input.pdh_cert_len, GFP_KERNEL);
+ if (!pdh_blob) {
+ ret = -ENOMEM;
+ goto e_free;
+ }
+
+ data->pdh_cert_address = __psp_pa(pdh_blob);
+ data->pdh_cert_len = input.pdh_cert_len;
+ }
+
+ cert_blob = NULL;
+ if (input.cert_chain_address) {
+ if (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free_pdh;
+ }
+
+ cert_blob = kmalloc(input.cert_chain_len, GFP_KERNEL);
+ if (!cert_blob) {
+ ret = -ENOMEM;
+ goto e_free_pdh;
+ }
+
+ data->cert_chain_address = __psp_pa(cert_blob);
+ data->cert_chain_len = input.cert_chain_len;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ /*
+ * CERT_EXPORT command can be issued in INIT or WORKING state.
+ * If we are in UNINIT state then transition into INIT state and
+ * shutdown before exiting. But if platform is in WORKING state
+ * then EXPORT the certificate but do not shutdown the platform.
+ */
+ if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ need_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+
+ input.cert_chain_len = data->cert_chain_len;
+ input.pdh_cert_len = data->pdh_cert_len;
+
+ /* copy certificate length to userspace */
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ ret = -EFAULT;
+
+ if (ret)
+ goto e_shutdown;
+
+ /* copy PDH certificate to userspace */
+ if (pdh_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.pdh_cert_address,
+ pdh_blob, input.pdh_cert_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+ /* copy certificate chain to userspace */
+ if (cert_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.cert_chain_address,
+ cert_blob, input.cert_chain_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+e_shutdown:
+ if (need_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+e_free_cert:
+ kfree(cert_blob);
+e_free_pdh:
+ kfree(pdh_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
+{
+ void __user *argp = (void __user *)arg;
+ struct sev_issue_cmd input;
+ int ret = -EFAULT;
+
+ if (ioctl != SEV_ISSUE_CMD)
+ return -EINVAL;
+
+ if (copy_from_user(&input, argp, sizeof(struct sev_issue_cmd)))
+ return -EFAULT;
+
+ if (input.cmd > SEV_CMD_MAX)
+ return -EINVAL;
+
+ switch (input.cmd) {
+
+ case SEV_USER_CMD_FACTORY_RESET: {
+ ret = sev_ioctl_factory_reset(&input);
+ break;
+ }
+ case SEV_USER_CMD_PLATFORM_STATUS: {
+ ret = sev_ioctl_platform_status(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_GEN: {
+ ret = sev_ioctl_pek_gen(&input);
+ break;
+ }
+ case SEV_USER_CMD_PDH_GEN: {
+ ret = sev_ioctl_pdh_gen(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_CSR: {
+ ret = sev_ioctl_pek_csr(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_CERT_IMPORT: {
+ ret = sev_ioctl_pek_cert_import(&input);
+ break;
+ }
+ case SEV_USER_CMD_PDH_CERT_EXPORT: {
+ ret = sev_ioctl_pdh_cert_export(&input);
+ break;
+ }
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
+ ret = -EFAULT;
+
+ return ret;
+}
+
+
+const struct file_operations sev_fops = {
+ .owner = THIS_MODULE,
+ .unlocked_ioctl = sev_ioctl,
+};
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_INIT, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+int sev_platform_shutdown(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_data_status *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_status);
+
+int sev_issue_cmd_external_user(struct file *filep, unsigned int cmd,
+ void *data, int *error)
+{
+ if (!filep || filep->f_op != &sev_fops)
+ return -EBADF;
+
+ return sev_handle_cmd(cmd, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_issue_cmd_external_user);
+
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DEACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_deactivate);
+
+int sev_guest_activate(struct sev_data_activate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_ACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_activate);
+
+int sev_guest_decommission(struct sev_data_decommission *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DECOMMISSION, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_decommission);
+
+int sev_guest_df_flush(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DF_FLUSH, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_df_flush);
+
+static int sev_ops_init(struct psp_device *psp)
+{
+ int ret = 0;
+ struct miscdevice *misc = &psp->sev_misc;
+
+ /*
+ * SEV feature support can be detected on the multiple devices but the
+ * SEV FW commands must be issued on the master. During probe time we
+ * do not know the master hence we create /dev/sev on the first device
+ * probe. sev_handle_cmd() finds the right master device to send the
+ * command.
+ */
+ if (!sev_fops_registered) {
+ misc->minor = MISC_DYNAMIC_MINOR;
+ misc->name = DEVICE_NAME;
+ misc->fops = &sev_fops;
+
+ ret = misc_register(misc);
+ if (!ret) {
+ sev_fops_registered = true;
+ psp->has_sev_fops = true;
+ init_waitqueue_head(&psp->sev_int_queue);
+ }
+ }
+
+ return ret;
+}
+
+static int sev_init(struct psp_device *psp)
+{
+ /* Check if device supports SEV feature */
+ if (!(ioread32(psp->io_regs + PSP_FEATURE_REG) & 1)) {
+ dev_dbg(psp->dev, "device does not support SEV\n");
+ return 1;
+ }
+
+ return sev_ops_init(psp);
+}
+
+static void sev_exit(struct psp_device *psp)
+{
+ if (psp->has_sev_fops)
+ misc_deregister(&psp->sev_misc);
+}
+
int psp_dev_init(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -87,14 +821,20 @@ int psp_dev_init(struct sp_device *sp)
sp_set_psp_master(sp);
+ ret = sev_init(psp);
+ if (ret)
+ goto e_irq;
+
/* Enable interrupt */
dev_dbg(dev, "Enabling interrupts ...\n");
- iowrite32(7, psp->io_regs + PSP_P2CMSG_INTEN);
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
dev_notice(dev, "psp enabled\n");
return 0;
+e_irq:
+ sp_free_psp_irq(psp->sp, psp);
e_err:
sp->psp_data = NULL;
@@ -107,5 +847,6 @@ void psp_dev_destroy(struct sp_device *sp)
{
struct psp_device *psp = sp->psp_data;
+ sev_exit(psp);
sp_free_psp_irq(sp, psp);
}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index d53970ef5960..51d3cd966eed 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -25,9 +25,21 @@
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
#include <linux/dmaengine.h>
+#include <linux/psp-sev.h>
+#include <linux/miscdevice.h>
#include "sp-dev.h"
+#define PSP_C2PMSG(_num) ((_num) << 2)
+#define PSP_CMDRESP PSP_C2PMSG(32)
+#define PSP_CMDBUFF_ADDR_LO PSP_C2PMSG(56)
+#define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
+#define PSP_FEATURE_REG PSP_C2PMSG(63)
+
+#define PSP_P2CMSG(_num) (_num << 2)
+#define PSP_CMD_COMPLETE_REG 1
+#define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
+
#define PSP_P2CMSG_INTEN 0x0110
#define PSP_P2CMSG_INTSTS 0x0114
@@ -54,6 +66,11 @@ struct psp_device {
struct sp_device *sp;
void __iomem *io_regs;
+
+ unsigned int sev_int_rcvd;
+ wait_queue_head_t sev_int_queue;
+ bool has_sev_fops;
+ struct miscdevice sev_misc;
};
extern const struct psp_vdata psp_entry;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index d40709b65b18..70ba2dcdba04 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -509,4 +509,175 @@ struct __attribute__((__packed__)) sev_data_dbg {
u32 len; /* In */
};
+#if defined(CONFIG_CRYPTO_DEV_SP_PSP)
+
+/**
+ * sev_platform_init - perform SEV INIT command
+ *
+ * @init: sev_data_init structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_init(struct sev_data_init *init, int *error);
+
+/**
+ * sev_platform_shutdown - perform SEV SHUTDOWN command
+ *
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_shutdown(int *error);
+
+/**
+ * sev_platform_status - perform SEV PLATFORM_STATUS command
+ *
+ * @init: sev_data_status structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_status(struct sev_data_status *status, int *error);
+/**
+ * sev_issue_cmd_external_user - issue SEV command by other driver with a file handle.
+ *
+ * The function can be used by other drivers to issue a SEV command on
+ * behalf by userspace. The caller must pass a valid SEV file descriptor
+ * so that we know that caller has access to SEV device.
+ *
+ * @filep - SEV device file pointer
+ * @cmd - command to issue
+ * @data - command buffer
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ * -%EINVAL if the SEV file descriptor is not valid
+ */
+int sev_issue_cmd_external_user(struct file *filep, unsigned int id,
+ void *data, int *error);
+
+/**
+ * sev_guest_deactivate - perform SEV DEACTIVATE command
+ *
+ * @deactivate: sev_data_deactivate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error);
+
+/**
+ * sev_guest_activate - perform SEV ACTIVATE command
+ *
+ * @activate: sev_data_activate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_activate(struct sev_data_activate *data, int *error);
+
+/**
+ * sev_guest_df_flush - perform SEV DF_FLUSH command
+ *
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_df_flush(int *error);
+
+/**
+ * sev_guest_decommission - perform SEV DECOMMISSION command
+ *
+ * @decommission: sev_data_decommission structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_decommission(struct sev_data_decommission *data, int *error);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int sev_platform_status(struct sev_data_status *status,
+ int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_platform_init(struct sev_data_init *init, int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_platform_shutdown(int *error) { return -ENODEV; }
+
+
+static inline int sev_issue_cmd_external_user(int fd, unsigned int id,
+ void *data, int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_guest_deactivate(struct sev_data_deactivate *data,
+ int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_guest_decommission(struct sev_data_decommission *data,
+ int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_guest_activate(struct sev_data_activate *data,
+ int *error)
+{
+ return -ENODEV;
+}
+
+static inline int sev_guest_df_flush(int *error) { return -ENODEV; }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif /* __PSP_SEV_H__ */
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
new file mode 100644
index 000000000000..885d9940786a
--- /dev/null
+++ b/include/uapi/linux/psp-sev.h
@@ -0,0 +1,114 @@
+
+/*
+ * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_SEV_USER_H__
+#define __PSP_SEV_USER_H__
+
+#include <linux/types.h>
+
+/**
+ * SEV platform commands
+ */
+enum {
+ SEV_USER_CMD_FACTORY_RESET = 0,
+ SEV_USER_CMD_PLATFORM_STATUS,
+ SEV_USER_CMD_PEK_GEN,
+ SEV_USER_CMD_PEK_CSR,
+ SEV_USER_CMD_PDH_GEN,
+ SEV_USER_CMD_PDH_CERT_EXPORT,
+ SEV_USER_CMD_PEK_CERT_IMPORT,
+
+ SEV_USER_CMD_MAX,
+};
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u8 owner : 1; /* Out */
+ __u8 reserved1 : 7;
+ __u32 config : 1; /* Out */
+ __u32 reserved2 : 23;
+ __u32 build : 8; /* Out */
+ __u32 guest_count; /* Out */
+} __attribute__ ((__packed__));
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+ __u64 address; /* In */
+ __u32 length; /* In/Out */
+};
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+ __u64 pek_cert_address; /* In */
+ __u32 pek_cert_len; /* In */
+ __u64 oca_cert_address; /* In */
+ __u32 oca_cert_len; /* In */
+};
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+ __u64 pdh_cert_address; /* In */
+ __u32 pdh_cert_len; /* In/Out */
+ __u64 cert_chain_address; /* In */
+ __u32 cert_chain_len; /* In/Out */
+};
+
+/**
+ * struct sev_issue_cmd - SEV ioctl parameters
+ *
+ * @cmd: SEV commands to execute
+ * @opaque: pointer to the command structure
+ * @error: SEV FW return code on failure
+ */
+struct sev_issue_cmd {
+ __u32 cmd; /* In */
+ __u64 data; /* In */
+ __u32 error; /* Out */
+};
+
+#define SEV_IOC_TYPE 'S'
+#define SEV_ISSUE_CMD _IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
+
+#endif /* __PSP_USER_SEV_H */
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH] crypto: ccp: fix eno.cocci warnings
2017-09-19 20:46 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-09-22 21:35 ` kbuild test robot
2017-09-22 21:35 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 21:35 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Paolo Bonzini,
Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
drivers/crypto/ccp/psp-dev.c:311:5-11: ERROR: allocation function on line 310 returns NULL not ERR_PTR on failure
The various basic memory allocation functions don't return ERR_PTR
Generated by: scripts/coccinelle/null/eno.cocci
Fixes: 7d4ce155f344 ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
CC: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
psp-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -308,7 +308,7 @@ static void *copy_user_blob(u64 __user u
return ERR_PTR(-EINVAL);
data = kmalloc(len, GFP_KERNEL);
- if (IS_ERR(data))
+ if (!data)
return ERR_PTR(-ENOMEM);
if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-09-19 20:46 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
2017-09-22 21:35 ` [PATCH] crypto: ccp: fix eno.cocci warnings kbuild test robot
@ 2017-09-22 21:35 ` kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 21:35 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Paolo Bonzini,
Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
Hi Brijesh,
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.14-rc1 next-20170922]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/x86-Secure-Encrypted-Virtualization-AMD/20170923-033600
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
coccinelle warnings: (new ones prefixed by >>)
>> drivers/crypto/ccp/psp-dev.c:311:5-11: ERROR: allocation function on line 310 returns NULL not ERR_PTR on failure
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 PATCH v4 08/29] KVM: SVM: Prepare to reserve asid for SEV guest
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (6 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 09/29] KVM: SVM: Reserve ASID range " Brijesh Singh
` (20 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
In current implementation, asid allocation starts from 1, adds a
min_asid variable in svm_vcpu structure to allow starting asid from
something other than 1.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8186b8d7c469..2c3a3c88596c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -525,6 +525,7 @@ struct svm_cpu_data {
u64 asid_generation;
u32 max_asid;
u32 next_asid;
+ u32 min_asid;
struct kvm_ldttss_desc *tss_desc;
struct page *save_area;
@@ -782,6 +783,7 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
+ sd->min_asid = 1;
gdt = get_current_gdt_rw();
sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
@@ -2091,7 +2093,7 @@ static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
{
if (sd->next_asid > sd->max_asid) {
++sd->asid_generation;
- sd->next_asid = 1;
+ sd->next_asid = sd->min_asid;
svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 09/29] KVM: SVM: Reserve ASID range for SEV guest
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (7 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 08/29] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 10/29] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
` (19 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
A SEV-enabled guest must use ASIDs from the defined subset, while non-SEV
guests can use the remaining ASID range. The range of ASID allowed SEV
guest ASIDs is [1 - CPUID_8000_001F[ECX][31:0]].
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2c3a3c88596c..360f4b90f48d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -319,6 +319,8 @@ enum {
#define VMCB_AVIC_APIC_BAR_MASK 0xFFFFFFFFFF000ULL
+static unsigned int max_sev_asid;
+
static inline void mark_all_dirty(struct vmcb *vmcb)
{
vmcb->control.clean = 0;
@@ -783,7 +785,7 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
- sd->min_asid = 1;
+ sd->min_asid = max_sev_asid + 1;
gdt = get_current_gdt_rw();
sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
@@ -1050,6 +1052,15 @@ static int avic_ga_log_notifier(u32 ga_tag)
return 0;
}
+/*
+ * Get maximum number of encrypted guest supported: Fn8001_001F[ECX].
+ * [31:0]: Number of supported guest
+ */
+static __init void sev_hardware_setup(void)
+{
+ max_sev_asid = cpuid_ecx(0x8000001F);
+}
+
static __init int svm_hardware_setup(void)
{
int cpu;
@@ -1080,6 +1091,9 @@ static __init int svm_hardware_setup(void)
kvm_tsc_scaling_ratio_frac_bits = 32;
}
+ if (boot_cpu_has(X86_FEATURE_SEV))
+ sev_hardware_setup();
+
if (nested) {
printk(KERN_INFO "kvm: Nested Virtualization enabled\n");
kvm_enable_efer_bits(EFER_SVME | EFER_LMSLE);
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 10/29] KVM: X86: Extend CPUID range to include new leaf
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (8 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 09/29] KVM: SVM: Reserve ASID range " Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 11/29] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
` (18 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
This CPUID leaf provides the memory encryption support information on
AMD Platform. Its complete description is available in APM volume 2,
Section 15.34
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/svm.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 0099e10eb045..c6473ca825cd 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -604,7 +604,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
entry->edx = 0;
break;
case 0x80000000:
- entry->eax = min(entry->eax, 0x8000001a);
+ entry->eax = min(entry->eax, 0x8000001f);
break;
case 0x80000001:
entry->edx &= kvm_cpuid_8000_0001_edx_x86_features;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 360f4b90f48d..3535aa510194 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5163,6 +5163,12 @@ static void svm_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
entry->edx |= SVM_FEATURE_NPT;
break;
+ case 0x8000001F:
+ /* Support memory encryption cpuid if host supports it */
+ if (boot_cpu_has(X86_FEATURE_SEV))
+ cpuid(0x8000001f, &entry->eax, &entry->ebx,
+ &entry->ecx, &entry->edx);
+
}
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 11/29] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (9 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 10/29] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 12/29] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl Brijesh Singh
` (17 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_OP ioctl can
be used by qemu to issue a platform specific memory encryption commands.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Documentation/virtual/kvm/api.txt | 15 +++++++++++++++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 12 ++++++++++++
include/uapi/linux/kvm.h | 2 ++
4 files changed, 31 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e63a35fafef0..3f0dc33d8a8b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3390,6 +3390,21 @@ invalid, if invalid pages are written to (e.g. after the end of memory)
or if no page table is present for the addresses (e.g. when using
hugepages).
+4.109 KVM_MEMORY_ENCRYPTION_OP
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: a opaque platform specific structure (in/out)
+Returns: 0 on success; -1 on error
+
+If platform supports creating encrypted VMs then this ioctl can be used for
+issuing a platform specific memory encryption commands to manage the encrypted
+VMs.
+
+Currently, this ioctl is used for issuing Secure Encrypted Virtualization (SEV)
+commands on AMD Processors.
+
5. The kvm_run structure
------------------------
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c73e493adf07..48001ca48c14 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1061,6 +1061,8 @@ struct kvm_x86_ops {
void (*cancel_hv_timer)(struct kvm_vcpu *vcpu);
void (*setup_mce)(struct kvm_vcpu *vcpu);
+
+ int (*mem_enc_op)(struct kvm *kvm, void __user *argp);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cd17b7d9a107..ec9f634b75f0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4010,6 +4010,14 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
return r;
}
+static int kvm_vm_ioctl_mem_enc_op(struct kvm *kvm, void __user *argp)
+{
+ if (kvm_x86_ops->mem_enc_op)
+ return kvm_x86_ops->mem_enc_op(kvm, argp);
+
+ return -ENOTTY;
+}
+
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -4270,6 +4278,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_enable_cap(kvm, &cap);
break;
}
+ case KVM_MEMORY_ENCRYPTION_OP: {
+ r = kvm_vm_ioctl_mem_enc_op(kvm, argp);
+ break;
+ }
default:
r = -ENOTTY;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 838887587411..23028a78f12f 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1356,6 +1356,8 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_S390_CMMA_MIGRATION */
#define KVM_S390_GET_CMMA_BITS _IOWR(KVMIO, 0xb8, struct kvm_s390_cmma_log)
#define KVM_S390_SET_CMMA_BITS _IOW(KVMIO, 0xb9, struct kvm_s390_cmma_log)
+/* Memory Encryption Commands */
+#define KVM_MEMORY_ENCRYPTION_OP _IOWR(KVMIO, 0xba, unsigned long)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 12/29] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (10 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 11/29] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 13/29] KVM: Define SEV key management command id Brijesh Singh
` (16 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REGISTER_REGION
and KVM_MEMORY_ENCRYPT_UNREGISTER_REGION ioctl's can be used by userspace to
register/unregister the guest memory regions which may contain the encrypted
data (e.g guest RAM, PCI BAR, SMRAM etc).
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Documentation/virtual/kvm/api.txt | 22 ++++++++++++++++++++++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 36 ++++++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 9 +++++++++
4 files changed, 69 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 3f0dc33d8a8b..f07b7b87cba9 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3405,6 +3405,28 @@ VMs.
Currently, this ioctl is used for issuing Secure Encrypted Virtualization (SEV)
commands on AMD Processors.
+4.110 KVM_MEMORY_ENCRYPTION_REGISTER_REGION
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: struct kvm_enc_region (in)
+Returns: 0 on success; -1 on error
+
+This ioctl can be used to register the guest memory region which may contain the
+encrypted data (e.g guest RAM, SMRAM etc).
+
+4.111 KVM_MEMORY_ENCRYPTION_UNREGISTER_REGION
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: struct kvm_enc_region (in)
+Returns: 0 on success; -1 on error
+
+This ioctl can be used to unregister the memory region registered with
+KVM_MEMORY_ENCRYPTION_REGISTER_REGION ioctl.
+
5. The kvm_run structure
------------------------
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 48001ca48c14..20fba8bfa727 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1063,6 +1063,8 @@ struct kvm_x86_ops {
void (*setup_mce)(struct kvm_vcpu *vcpu);
int (*mem_enc_op)(struct kvm *kvm, void __user *argp);
+ int (*mem_enc_register_region)(struct kvm *kvm, struct kvm_enc_region *argp);
+ int (*mem_enc_unregister_region)(struct kvm *kvm, struct kvm_enc_region *argp);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ec9f634b75f0..b00035488569 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4018,6 +4018,24 @@ static int kvm_vm_ioctl_mem_enc_op(struct kvm *kvm, void __user *argp)
return -ENOTTY;
}
+static int kvm_vm_ioctl_mem_enc_register_region(struct kvm *kvm,
+ struct kvm_enc_region *region)
+{
+ if (kvm_x86_ops->mem_enc_register_region)
+ return kvm_x86_ops->mem_enc_register_region(kvm, region);
+
+ return -ENOTTY;
+}
+
+static int kvm_vm_ioctl_mem_enc_unregister_region(struct kvm *kvm,
+ struct kvm_enc_region *region)
+{
+ if (kvm_x86_ops->mem_enc_unregister_region)
+ return kvm_x86_ops->mem_enc_unregister_region(kvm, region);
+
+ return -ENOTTY;
+}
+
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -4282,6 +4300,24 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_mem_enc_op(kvm, argp);
break;
}
+ case KVM_MEMORY_ENCRYPTION_REGISTER_REGION: {
+ struct kvm_enc_region region;
+
+ r = -EFAULT;
+ if (copy_from_user(®ion, argp, sizeof(region)))
+ goto out;
+ r = kvm_vm_ioctl_mem_enc_register_region(kvm, ®ion);
+ break;
+ }
+ case KVM_MEMORY_ENCRYPTION_UNREGISTER_REGION: {
+ struct kvm_enc_region region;
+
+ r = -EFAULT;
+ if (copy_from_user(®ion, argp, sizeof(region)))
+ goto out;
+ r = kvm_vm_ioctl_mem_enc_unregister_region(kvm, ®ion);
+ break;
+ }
default:
r = -ENOTTY;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 23028a78f12f..fc1825440a14 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1358,6 +1358,15 @@ struct kvm_s390_ucas_mapping {
#define KVM_S390_SET_CMMA_BITS _IOW(KVMIO, 0xb9, struct kvm_s390_cmma_log)
/* Memory Encryption Commands */
#define KVM_MEMORY_ENCRYPTION_OP _IOWR(KVMIO, 0xba, unsigned long)
+#define KVM_MEMORY_ENCRYPTION_REGISTER_REGION _IOR(KVMIO, 0xbb,\
+ struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPTION_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
+ struct kvm_enc_region)
+
+struct kvm_enc_region {
+ __u64 addr;
+ __u64 size;
+};
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 13/29] KVM: Define SEV key management command id
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (11 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 12/29] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 14/29] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
` (15 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
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@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/uapi/linux/kvm.h | 141 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 141 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index fc1825440a14..c94844f4d8cc 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1368,6 +1368,147 @@ struct kvm_enc_region {
__u64 size;
};
+/* Secure Encrypted Virtualization command */
+enum sev_cmd_id {
+ /* Guest initialization commands */
+ KVM_SEV_INIT = 0,
+ KVM_SEV_ES_INIT,
+ /* Guest launch commands */
+ KVM_SEV_LAUNCH_START,
+ KVM_SEV_LAUNCH_UPDATE_DATA,
+ KVM_SEV_LAUNCH_UPDATE_VMSA,
+ KVM_SEV_LAUNCH_SECRET,
+ KVM_SEV_LAUNCH_MEASURE,
+ KVM_SEV_LAUNCH_FINISH,
+ /* Guest migration commands (outgoing) */
+ KVM_SEV_SEND_START,
+ KVM_SEV_SEND_UPDATE_DATA,
+ KVM_SEV_SEND_UPDATE_VMSA,
+ KVM_SEV_SEND_FINISH,
+ /* Guest migration commands (incoming) */
+ KVM_SEV_RECEIVE_START,
+ KVM_SEV_RECEIVE_UPDATE_DATA,
+ KVM_SEV_RECEIVE_UPDATE_VMSA,
+ KVM_SEV_RECEIVE_FINISH,
+ /* Guest status and debug commands */
+ KVM_SEV_GUEST_STATUS,
+ KVM_SEV_DBG_DECRYPT,
+ KVM_SEV_DBG_ENCRYPT,
+ /* Guest certificates commands */
+ KVM_SEV_CERT_EXPORT,
+
+ KVM_SEV_NR_MAX,
+};
+
+struct kvm_sev_cmd {
+ __u32 id;
+ __u64 data;
+ __u32 error;
+ __u32 sev_fd;
+};
+
+struct kvm_sev_launch_start {
+ __u32 handle;
+ __u32 policy;
+ __u64 dh_uaddr;
+ __u32 dh_len;
+ __u64 session_uaddr;
+ __u32 session_len;
+};
+
+struct kvm_sev_launch_update_data {
+ __u64 uaddr;
+ __u32 len;
+};
+
+struct kvm_sev_launch_update_vmsa {
+ __u64 uaddr;
+ __u32 len;
+};
+
+struct kvm_sev_launch_secret {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_launch_measure {
+ __u64 uaddr;
+ __u32 len;
+};
+
+struct kvm_sev_send_start {
+ __u32 policy;
+ __u64 pdh_cert_uaddr;
+ __u32 pdh_cert_len;
+ __u64 plat_cert_uaddr;
+ __u32 plat_cert_len;
+ __u64 amd_cert_uaddr;
+ __u32 amd_cert_len;
+ __u64 session_uaddr;
+ __u32 session_len;
+};
+
+struct kvm_sev_send_update_data {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_send_update_vmsa {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_receive_start {
+ __u32 handle;
+ __u32 policy;
+ __u64 pdh_uaddr;
+ __u32 pdh_len;
+ __u64 session_uaddr;
+ __u32 session_len;
+};
+
+struct kvm_sev_receive_update_data {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_receive_update_vmsa {
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+ __u64 guest_uaddr;
+ __u32 guest_len;
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
+
+struct kvm_sev_guest_status {
+ __u32 handle;
+ __u32 policy;
+ __u32 state;
+};
+
+struct kvm_sev_dbg {
+ __u64 src_uaddr;
+ __u64 dst_uaddr;
+ __u32 len;
+};
+
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
#define KVM_DEV_ASSIGN_MASK_INTX (1 << 2)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 14/29] KVM: SVM: Add KVM_SEV_INIT command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (12 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 13/29] KVM: Define SEV key management command id Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 15/29] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
` (14 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command initializes the SEV firmware and allocates a new ASID for
this guest from the SEV ASID pool. The firmware must be initialized
before we issue any guest launch commands to create a new memory
encryption context.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 7 ++
arch/x86/kvm/svm.c | 184 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 190 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 20fba8bfa727..6bd49e80a16d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -747,6 +747,11 @@ enum kvm_irqchip_mode {
KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */
};
+struct kvm_sev_info {
+ bool active; /* SEV enabled guest */
+ unsigned int asid; /* ASID used for this guest */
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
@@ -834,6 +839,8 @@ struct kvm_arch {
bool x2apic_format;
bool x2apic_broadcast_quirk_disabled;
+
+ struct kvm_sev_info sev_info;
};
struct kvm_vm_stat {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3535aa510194..229bb7d09c44 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -37,6 +37,8 @@
#include <linux/amd-iommu.h>
#include <linux/hashtable.h>
#include <linux/frame.h>
+#include <linux/psp-sev.h>
+#include <linux/file.h>
#include <asm/apic.h>
#include <asm/perf_event.h>
@@ -320,6 +322,19 @@ enum {
#define VMCB_AVIC_APIC_BAR_MASK 0xFFFFFFFFFF000ULL
static unsigned int max_sev_asid;
+static unsigned long *sev_asid_bitmap;
+
+static inline bool svm_sev_enabled(void)
+{
+ return max_sev_asid;
+}
+
+static inline bool sev_guest(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ return sev->active;
+}
static inline void mark_all_dirty(struct vmcb *vmcb)
{
@@ -1059,6 +1074,11 @@ static int avic_ga_log_notifier(u32 ga_tag)
static __init void sev_hardware_setup(void)
{
max_sev_asid = cpuid_ecx(0x8000001F);
+
+ /* Initialize SEV ASID bitmap */
+ if (max_sev_asid)
+ sev_asid_bitmap = kcalloc(BITS_TO_LONGS(max_sev_asid),
+ sizeof(unsigned long), GFP_KERNEL);
}
static __init int svm_hardware_setup(void)
@@ -1156,10 +1176,45 @@ static __init int svm_hardware_setup(void)
return r;
}
+static int sev_platform_get_state(int *state, int *error)
+{
+ int ret;
+ struct sev_data_status *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_platform_status(data, error);
+ if (!ret)
+ *state = data->state;
+
+ pr_info_once("SEV firmware major %d minor %d build %d\n",
+ data->api_major, data->api_minor, data->build);
+
+ kfree(data);
+ return ret;
+}
+
+static __exit void sev_hardware_unsetup(void)
+{
+ int state;
+
+ sev_platform_get_state(&state, NULL);
+
+ if (state != SEV_STATE_UNINIT)
+ sev_platform_shutdown(NULL);
+
+ kfree(sev_asid_bitmap);
+}
+
static __exit void svm_hardware_unsetup(void)
{
int cpu;
+ if (svm_sev_enabled())
+ sev_hardware_unsetup();
+
for_each_possible_cpu(cpu)
svm_cpu_uninit(cpu);
@@ -1350,6 +1405,9 @@ static void init_vmcb(struct vcpu_svm *svm)
svm->vmcb->control.int_ctl |= V_GIF_ENABLE_MASK;
}
+ if (sev_guest(svm->vcpu.kvm))
+ svm->vmcb->control.nested_ctl |= SVM_NESTED_CTL_SEV_ENABLE;
+
mark_all_dirty(svm->vmcb);
enable_gif(svm);
@@ -1432,6 +1490,35 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
return 0;
}
+static void sev_firmware_exit(void)
+{
+ int state;
+
+ sev_platform_get_state(&state, NULL);
+
+ if (state == SEV_STATE_INIT)
+ sev_platform_shutdown(NULL);
+}
+
+static void sev_asid_free(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ int pos, asid;
+
+ if (svm_sev_enabled())
+ return;
+
+ asid = sev->asid;
+ pos = asid - 1;
+ clear_bit(pos, sev_asid_bitmap);
+}
+
+static void sev_vm_destroy(struct kvm *kvm)
+{
+ sev_asid_free(kvm);
+ sev_firmware_exit();
+}
+
static void avic_vm_destroy(struct kvm *kvm)
{
unsigned long flags;
@@ -1450,6 +1537,14 @@ static void avic_vm_destroy(struct kvm *kvm)
spin_unlock_irqrestore(&svm_vm_data_hash_lock, flags);
}
+static void svm_vm_destroy(struct kvm *kvm)
+{
+ avic_vm_destroy(kvm);
+
+ if (sev_guest(kvm))
+ sev_vm_destroy(kvm);
+}
+
static int avic_vm_init(struct kvm *kvm)
{
unsigned long flags;
@@ -5416,6 +5511,91 @@ static void svm_setup_mce(struct kvm_vcpu *vcpu)
vcpu->arch.mcg_cap &= 0x1ff;
}
+static int sev_asid_new(void)
+{
+ int pos;
+
+ if (!svm_sev_enabled())
+ return -EINVAL;
+
+ pos = find_first_zero_bit(sev_asid_bitmap, max_sev_asid);
+ if (pos >= max_sev_asid)
+ return -EBUSY;
+
+ set_bit(pos, sev_asid_bitmap);
+ return pos + 1;
+}
+
+static int sev_firmware_init(struct kvm *kvm, int *error)
+{
+ int ret, state;
+
+ ret = sev_platform_get_state(&state, error);
+ if (ret)
+ return ret;
+
+ /* If SEV firmware is in uninitialized state, lets initialize it. */
+ if (state == SEV_STATE_UNINIT) {
+ struct sev_data_init *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_platform_init(data, error);
+ kfree(data);
+ }
+
+ return ret;
+}
+
+static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ int asid, ret;
+
+ ret = sev_firmware_init(kvm, &argp->error);
+ if (ret)
+ return ret;
+
+ ret = -EBUSY;
+ asid = sev_asid_new();
+ if (asid < 0)
+ goto e_shutdown;
+
+ sev->active = true;
+ sev->asid = asid;
+ return 0;
+e_shutdown:
+ sev_firmware_exit();
+ return ret;
+}
+
+static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
+{
+ struct kvm_sev_cmd sev_cmd;
+ int r = -ENOTTY;
+
+ if (copy_from_user(&sev_cmd, argp, sizeof(struct kvm_sev_cmd)))
+ return -EFAULT;
+
+ mutex_lock(&kvm->lock);
+
+ switch (sev_cmd.id) {
+ case KVM_SEV_INIT: {
+ r = sev_guest_init(kvm, &sev_cmd);
+ break;
+ }
+ default:
+ break;
+ }
+
+ mutex_unlock(&kvm->lock);
+ if (copy_to_user(argp, &sev_cmd, sizeof(struct kvm_sev_cmd)))
+ r = -EFAULT;
+ return r;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -5432,7 +5612,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.vcpu_reset = svm_vcpu_reset,
.vm_init = avic_vm_init,
- .vm_destroy = avic_vm_destroy,
+ .vm_destroy = svm_vm_destroy,
.prepare_guest_switch = svm_prepare_guest_switch,
.vcpu_load = svm_vcpu_load,
@@ -5526,6 +5706,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.deliver_posted_interrupt = svm_deliver_avic_intr,
.update_pi_irte = svm_update_pi_irte,
.setup_mce = svm_setup_mce,
+
+ .mem_enc_op = svm_mem_enc_op,
};
static int __init svm_init(void)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 15/29] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (13 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 14/29] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command Brijesh Singh
` (13 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
SEV hardware uses ASIDs to associate memory encryption key with the
guest VMs. During the guest creation time, SEV VM use SEV_CMD_ACTIVATE
command to bind a particular ASID to the guest. Lets make sure that the
VMCB is programmed with the bound ASID before a VMRUN.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 229bb7d09c44..0149bfa75bb2 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -213,6 +213,9 @@ struct vcpu_svm {
*/
struct list_head ir_list;
spinlock_t ir_list_lock;
+
+ /* which host CPU was used for running this vcpu */
+ unsigned int last_cpu;
};
/*
@@ -336,6 +339,13 @@ static inline bool sev_guest(struct kvm *kvm)
return sev->active;
}
+static inline int sev_get_asid(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ return sev->asid;
+}
+
static inline void mark_all_dirty(struct vmcb *vmcb)
{
vmcb->control.clean = 0;
@@ -546,6 +556,9 @@ struct svm_cpu_data {
struct kvm_ldttss_desc *tss_desc;
struct page *save_area;
+
+ /* index = sev_asid, value = vmcb pointer */
+ struct vmcb **sev_vmcbs;
};
static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
@@ -859,6 +872,7 @@ static void svm_cpu_uninit(int cpu)
return;
per_cpu(svm_data, raw_smp_processor_id()) = NULL;
+ kfree(sd->sev_vmcbs);
__free_page(sd->save_area);
kfree(sd);
}
@@ -872,11 +886,18 @@ static int svm_cpu_init(int cpu)
if (!sd)
return -ENOMEM;
sd->cpu = cpu;
- sd->save_area = alloc_page(GFP_KERNEL);
r = -ENOMEM;
+ sd->save_area = alloc_page(GFP_KERNEL);
if (!sd->save_area)
goto err_1;
+ if (svm_sev_enabled()) {
+ r = -ENOMEM;
+ sd->sev_vmcbs = kmalloc((max_sev_asid + 1) * sizeof(void *), GFP_KERNEL);
+ if (!sd->sev_vmcbs)
+ goto err_1;
+ }
+
per_cpu(svm_data, cpu) = sd;
return 0;
@@ -1503,7 +1524,8 @@ static void sev_firmware_exit(void)
static void sev_asid_free(struct kvm *kvm)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
- int pos, asid;
+ struct svm_cpu_data *sd;
+ int pos, asid, cpu;
if (svm_sev_enabled())
return;
@@ -1511,6 +1533,11 @@ static void sev_asid_free(struct kvm *kvm)
asid = sev->asid;
pos = asid - 1;
clear_bit(pos, sev_asid_bitmap);
+
+ for_each_possible_cpu(cpu) {
+ sd = per_cpu(svm_data, cpu);
+ sd->sev_vmcbs[pos] = NULL;
+ }
}
static void sev_vm_destroy(struct kvm *kvm)
@@ -4444,12 +4471,39 @@ static void reload_tss(struct kvm_vcpu *vcpu)
load_TR_desc();
}
+static void pre_sev_run(struct vcpu_svm *svm, int cpu)
+{
+ struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
+ int asid = sev_get_asid(svm->vcpu.kvm);
+
+ /* Assign the asid allocated with this SEV guest */
+ svm->vmcb->control.asid = asid;
+
+ /*
+ * Flush guest TLB:
+ *
+ * 1) when different VMCB for the same ASID is to be run on the same host CPU.
+ * 2) or this VMCB was executed on different host CPU in previous VMRUNs.
+ */
+ if (sd->sev_vmcbs[asid] == svm->vmcb &&
+ svm->last_cpu == cpu)
+ return;
+
+ svm->last_cpu = cpu;
+ sd->sev_vmcbs[asid] = svm->vmcb;
+ svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ASID;
+ mark_dirty(svm->vmcb, VMCB_ASID);
+}
+
static void pre_svm_run(struct vcpu_svm *svm)
{
int cpu = raw_smp_processor_id();
struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
+ if (sev_guest(svm->vcpu.kvm))
+ return pre_sev_run(svm, cpu);
+
/* FIXME: handle wraparound of asid_generation */
if (svm->asid_generation != sd->asid_generation)
new_asid(svm, sd);
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (14 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 15/29] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-22 22:13 ` [PATCH] KVM: SVM: fix eno.cocci warnings kbuild test robot
2017-09-22 22:13 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command kbuild test robot
2017-09-19 20:46 ` [Part2 PATCH v4 17/29] KVM: SVM: Add support for SEV LAUNCH_UPDATE_DATA command Brijesh Singh
` (12 subsequent siblings)
28 siblings, 2 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for creating a memory encryption context.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 2 +
arch/x86/kvm/svm.c | 194 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 196 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6bd49e80a16d..7453ef7cb487 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -750,6 +750,8 @@ enum kvm_irqchip_mode {
struct kvm_sev_info {
bool active; /* SEV enabled guest */
unsigned int asid; /* ASID used for this guest */
+ unsigned int handle; /* SEV firmware handle */
+ int fd; /* SEV device fd */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0149bfa75bb2..5e3e7d46270b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1540,10 +1540,54 @@ static void sev_asid_free(struct kvm *kvm)
}
}
+static void sev_decommission_handle(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_decommission *data;
+
+ if (!sev->handle)
+ return;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return;
+
+ data->handle = sev->handle;
+ sev_guest_decommission(data, NULL);
+ kfree(data);
+}
+
+static void sev_deactivate_handle(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_deactivate *data;
+
+ if (!sev->handle)
+ return;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return;
+
+ data->handle = sev->handle;
+ sev_guest_deactivate(data, NULL);
+
+ wbinvd_on_all_cpus();
+ sev_guest_df_flush(NULL);
+
+ kfree(data);
+}
+
static void sev_vm_destroy(struct kvm *kvm)
{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ sev_deactivate_handle(kvm);
+ sev_decommission_handle(kvm);
sev_asid_free(kvm);
sev_firmware_exit();
+
+ memset(sev, 0x00, sizeof(*sev));
}
static void avic_vm_destroy(struct kvm *kvm)
@@ -5625,6 +5669,152 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_activate_asid(struct kvm *kvm, unsigned int handle, int *error)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_activate *data;
+ int asid = sev_get_asid(kvm);
+ int ret;
+
+ wbinvd_on_all_cpus();
+
+ ret = sev_guest_df_flush(error);
+ if (ret)
+ return ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = handle;
+ data->asid = asid;
+ ret = sev_guest_activate(data, error);
+ if (ret)
+ goto e_err;
+
+ sev->asid = asid;
+e_err:
+ kfree(data);
+ return ret;
+}
+
+static int sev_issue_cmd(int fd, int id, void *data, int *error)
+{
+ struct fd f;
+ int ret;
+
+ f = fdget(fd);
+ if (!f.file)
+ return -EBADF;
+
+ ret = sev_issue_cmd_external_user(f.file, id, data, error);
+
+ fdput(f);
+ return ret;
+}
+
+static void *copy_user_blob(u64 __user uaddr, u32 len)
+{
+ void *data;
+
+ if (!uaddr || !len)
+ return ERR_PTR(-EINVAL);
+
+ /* verify that blob length does not exceed our limit */
+ if (len > SEV_FW_BLOB_MAX_SIZE)
+ return ERR_PTR(-EINVAL);
+
+ data = kmalloc(len, GFP_KERNEL);
+ if (IS_ERR(data))
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ goto e_free;
+
+ return data;
+e_free:
+ kfree(data);
+ return ERR_PTR(-EFAULT);
+}
+
+static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_start *start;
+ struct kvm_sev_launch_start params;
+ void *dh_blob, *session_blob;
+ int *error = &argp->error;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_start)))
+ return -EFAULT;
+
+ start = kzalloc(sizeof(*start), GFP_KERNEL);
+ if (!start)
+ return -ENOMEM;
+
+ dh_blob = NULL;
+ if (params.dh_uaddr) {
+ dh_blob = copy_user_blob(params.dh_uaddr, params.dh_len);
+ if (IS_ERR(dh_blob)) {
+ ret = PTR_ERR(dh_blob);
+ goto e_free;
+ }
+
+ start->dh_cert_address = __sme_set(__pa(dh_blob));
+ start->dh_cert_len = params.dh_len;
+ }
+
+ session_blob = NULL;
+ if (params.session_uaddr) {
+ dh_blob = copy_user_blob(params.session_uaddr, params.session_len);
+ if (IS_ERR(session_blob)) {
+ ret = PTR_ERR(session_blob);
+ goto e_free_dh;
+ }
+
+ start->session_address = __sme_set(__pa(session_blob));
+ start->session_len = params.session_len;
+ }
+
+ start->handle = params.handle;
+ start->policy = params.policy;
+
+ /* create memory encryption context */
+ ret = sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
+ if (ret)
+ goto e_free_session;
+
+ sev->handle = start->handle;
+
+ /* Bind ASID to this guest */
+ ret = sev_activate_asid(kvm, start->handle, error);
+ if (ret)
+ goto e_free_session;
+
+ /* return handle to userspace */
+ params.handle = start->handle;
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
+ sizeof(struct kvm_sev_launch_start))) {
+ sev_vm_destroy(kvm);
+ ret = -EFAULT;
+ goto e_free_session;
+ }
+
+ sev->fd = argp->sev_fd;
+e_free_session:
+ kfree(session_blob);
+e_free_dh:
+ kfree(dh_blob);
+e_free:
+ kfree(start);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -5640,6 +5830,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_guest_init(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_START: {
+ r = sev_launch_start(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH] KVM: SVM: fix eno.cocci warnings
2017-09-19 20:46 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command Brijesh Singh
@ 2017-09-22 22:13 ` kbuild test robot
2017-09-22 22:13 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 22:13 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
arch/x86/kvm/svm.c:5728:5-11: ERROR: allocation function on line 5727 returns NULL not ERR_PTR on failure
The various basic memory allocation functions don't return ERR_PTR
Generated by: scripts/coccinelle/null/eno.cocci
Fixes: 16e737dd7c3c ("KVM: SVM: Add support for SEV LAUNCH_START command")
CC: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5725,7 +5725,7 @@ static void *copy_user_blob(u64 __user u
return ERR_PTR(-EINVAL);
data = kmalloc(len, GFP_KERNEL);
- if (IS_ERR(data))
+ if (!data)
return ERR_PTR(-ENOMEM);
if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command
2017-09-19 20:46 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command Brijesh Singh
2017-09-22 22:13 ` [PATCH] KVM: SVM: fix eno.cocci warnings kbuild test robot
@ 2017-09-22 22:13 ` kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 22:13 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
Hi Brijesh,
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.14-rc1 next-20170922]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/x86-Secure-Encrypted-Virtualization-AMD/20170923-033600
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
coccinelle warnings: (new ones prefixed by >>)
>> arch/x86/kvm/svm.c:5728:5-11: ERROR: allocation function on line 5727 returns NULL not ERR_PTR on failure
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Part2 PATCH v4 17/29] KVM: SVM: Add support for SEV LAUNCH_UPDATE_DATA command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (15 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 16/29] KVM: SVM: Add support for SEV LAUNCH_START command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 18/29] KVM: SVM: Add support for SEV LAUNCH_MEASURE command Brijesh Singh
` (11 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for encrypting the guest memory region using the VM
encryption key (VEK) created during KVM_SEV_LAUNCH_START.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 191 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 190 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7453ef7cb487..86006dcfe574 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -752,6 +752,7 @@ struct kvm_sev_info {
unsigned int asid; /* ASID used for this guest */
unsigned int handle; /* SEV firmware handle */
int fd; /* SEV device fd */
+ unsigned long locked; /* Number of pages locked */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5e3e7d46270b..4667504acca5 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -39,6 +39,8 @@
#include <linux/frame.h>
#include <linux/psp-sev.h>
#include <linux/file.h>
+#include <linux/pagemap.h>
+#include <linux/swap.h>
#include <asm/apic.h>
#include <asm/perf_event.h>
@@ -326,6 +328,7 @@ enum {
static unsigned int max_sev_asid;
static unsigned long *sev_asid_bitmap;
+#define __sme_page_pa(x) __sme_set(page_to_pfn(x) << PAGE_SHIFT)
static inline bool svm_sev_enabled(void)
{
@@ -1578,6 +1581,82 @@ static void sev_deactivate_handle(struct kvm *kvm)
kfree(data);
}
+static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
+ unsigned long ulen, unsigned long *n,
+ int write)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ unsigned long npages, pinned, size;
+ unsigned long locked, lock_limit;
+ struct page **pages;
+ int first, last;
+
+ /* calculate number of pages */
+ first = (uaddr & PAGE_MASK) >> PAGE_SHIFT;
+ last = ((uaddr + ulen - 1) & PAGE_MASK) >> PAGE_SHIFT;
+ npages = (last - first + 1);
+
+ locked = sev->locked + npages;
+ lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+ if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
+ pr_err("locked(%lu) > lock_limit(%lu)\n", locked, lock_limit);
+ return NULL;
+ }
+
+ /* Avoid using vmalloc for smaller buffer */
+ size = npages * sizeof(struct page *);
+ if (size > PAGE_SIZE)
+ pages = vmalloc(size);
+ else
+ pages = kmalloc(size, GFP_KERNEL);
+
+ if (!pages)
+ return NULL;
+
+ /* pin the user virtual address */
+ pinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0, pages);
+ if (pinned != npages) {
+ pr_err("failed to lock %lu\n", npages);
+ goto err;
+ }
+
+ *n = npages;
+ sev->locked = locked;
+
+ return pages;
+err:
+ if (pinned > 0)
+ release_pages(pages, pinned, 0);
+
+ kvfree(pages);
+ return NULL;
+}
+
+static void sev_unpin_memory(struct kvm *kvm, struct page **pages,
+ unsigned long npages)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ sev->locked -= npages;
+ release_pages(pages, npages, 0);
+ kvfree(pages);
+}
+
+static void sev_clflush_pages(struct page *pages[], unsigned long npages)
+{
+ uint8_t *page_virtual;
+ unsigned long i;
+
+ if (npages == 0 || pages == NULL)
+ return;
+
+ for (i = 0; i < npages; i++) {
+ page_virtual = kmap_atomic(pages[i]);
+ clflush_cache_range(page_virtual, PAGE_SIZE);
+ kunmap_atomic(page_virtual);
+ }
+}
+
static void sev_vm_destroy(struct kvm *kvm)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
@@ -5698,7 +5777,7 @@ static int sev_activate_asid(struct kvm *kvm, unsigned int handle, int *error)
return ret;
}
-static int sev_issue_cmd(int fd, int id, void *data, int *error)
+static int __sev_issue_cmd(int fd, int id, void *data, int *error)
{
struct fd f;
int ret;
@@ -5713,6 +5792,13 @@ static int sev_issue_cmd(int fd, int id, void *data, int *error)
return ret;
}
+static int sev_issue_cmd(struct kvm *kvm, int id, void *data, int *error)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ return __sev_issue_cmd(sev->fd, id, data, error);
+}
+
static void *copy_user_blob(u64 __user uaddr, u32 len)
{
void *data;
@@ -5785,7 +5871,7 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
start->policy = params.policy;
/* create memory encryption context */
- ret = sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
+ ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
if (ret)
goto e_free_session;
@@ -5815,6 +5901,103 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int get_num_contig_pages(int idx, struct page **inpages,
+ unsigned long npages)
+{
+ int i = idx + 1, pages = 1;
+ unsigned long paddr, next_paddr;
+
+ /* find the number of contiguous pages starting from idx */
+ paddr = __sme_page_pa(inpages[idx]);
+ while (i < npages) {
+ next_paddr = __sme_page_pa(inpages[i++]);
+ if ((paddr + PAGE_SIZE) == next_paddr) {
+ pages++;
+ paddr = next_paddr;
+ continue;
+ }
+ break;
+ }
+
+ return pages;
+}
+
+static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ unsigned long vaddr, vaddr_end, next_vaddr, npages, size;
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct kvm_sev_launch_update_data params;
+ struct sev_data_launch_update_data *data;
+ struct page **inpages;
+ int i, ret, pages;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_update_data)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ vaddr = params.uaddr;
+ size = params.len;
+ vaddr_end = vaddr + size;
+
+ /* lock the user memory */
+ inpages = sev_pin_memory(kvm, vaddr, size, &npages, 1);
+ if (!inpages) {
+ ret = -ENOMEM;
+ goto e_free;
+ }
+
+ /*
+ * PSP will perform the in-place encryption of the memory content (it
+ * may access the memory range with C=1). Lets make sure that caches
+ * are flushed so that data is written in DRAM with correct C-bit before
+ * PSP accesses it.
+ */
+ sev_clflush_pages(inpages, npages);
+
+ for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i += pages) {
+ int offset, len;
+
+ /*
+ * since user buffer may not be page aligned, calculate the
+ * offset within the page.
+ */
+ offset = vaddr & (PAGE_SIZE - 1);
+
+ /* calculate the number of pages that can be encrypted in one go */
+ pages = get_num_contig_pages(i, inpages, npages);
+
+ len = min_t(size_t, ((pages * PAGE_SIZE) - offset), size);
+
+ data->handle = sev->handle;
+ data->len = len;
+ data->address = __sme_page_pa(inpages[i]) + offset;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_DATA, data, &argp->error);
+ if (ret)
+ goto e_unpin;
+
+ size -= len;
+ next_vaddr = vaddr + len;
+ }
+e_unpin:
+ /* content of memory is updated, mark pages dirty */
+ for (i = 0; i < npages; i++) {
+ set_page_dirty_lock(inpages[i]);
+ mark_page_accessed(inpages[i]);
+ }
+ /* unlock the user pages */
+ sev_unpin_memory(kvm, inpages, npages);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -5834,6 +6017,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_start(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_UPDATE_DATA: {
+ r = sev_launch_update_data(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 18/29] KVM: SVM: Add support for SEV LAUNCH_MEASURE command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (16 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 17/29] KVM: SVM: Add support for SEV LAUNCH_UPDATE_DATA command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 19/29] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
` (10 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used to retrieve the measurement of memory encrypted
through the LAUNCH_UPDATE_DATA command.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4667504acca5..b7099fd8b641 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5998,6 +5998,63 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_launch_measure(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_measure *data;
+ struct kvm_sev_launch_measure params;
+ void *blob;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_measure)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ blob = NULL;
+ if (params.uaddr) {
+ if (params.len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free;
+ }
+
+ ret = -ENOMEM;
+ blob = kzalloc(params.len, GFP_KERNEL);
+ if (!blob)
+ goto e_free;
+
+ data->address = __psp_pa(blob);
+ data->len = params.len;
+ }
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_MEASURE, data, &argp->error);
+
+ /* copy the measurement to userspace */
+ if (blob &&
+ copy_to_user((void __user *)(uintptr_t)params.uaddr, blob, params.len)) {
+ ret = -EFAULT;
+ goto e_free_blob;
+ }
+
+ params.len = data->len;
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
+ sizeof(struct kvm_sev_launch_measure)))
+ ret = -EFAULT;
+
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6021,6 +6078,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_update_data(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_MEASURE: {
+ r = sev_launch_measure(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 19/29] KVM: SVM: Add support for SEV LAUNCH_FINISH command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (17 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 18/29] KVM: SVM: Add support for SEV LAUNCH_MEASURE command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 20/29] KVM: svm: Add support for SEV GUEST_STATUS command Brijesh Singh
` (9 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for finializing the SEV guest launch process.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b7099fd8b641..c1688542df72 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6055,6 +6055,26 @@ static int sev_launch_measure(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_finish *data;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_FINISH, data, &argp->error);
+
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6082,6 +6102,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_measure(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_FINISH: {
+ r = sev_launch_finish(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 20/29] KVM: svm: Add support for SEV GUEST_STATUS command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (18 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 19/29] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 21/29] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
` (8 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for querying the SEV guest status.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index c1688542df72..7a6e82c48142 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6075,6 +6075,37 @@ static int sev_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_guest_status(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct kvm_sev_guest_status params;
+ struct sev_data_guest_status *data;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_GUEST_STATUS, data, &argp->error);
+ if (ret)
+ goto e_free;
+
+ params.policy = data->policy;
+ params.state = data->state;
+ params.handle = data->handle;
+
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
+ sizeof(struct kvm_sev_guest_status)))
+ ret = -EFAULT;
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6106,6 +6137,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_finish(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_GUEST_STATUS: {
+ r = sev_guest_status(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 21/29] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (19 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 20/29] KVM: svm: Add support for SEV GUEST_STATUS command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 22/29] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
` (7 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for decrypting a guest memory region for debug
purposes.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 179 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7a6e82c48142..4d51ccb462db 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1622,7 +1622,6 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
*n = npages;
sev->locked = locked;
-
return pages;
err:
if (pinned > 0)
@@ -6106,6 +6105,181 @@ static int sev_guest_status(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int __sev_issue_dbg_cmd(struct kvm *kvm, unsigned long src,
+ unsigned long dst, int size,
+ int *error, bool enc)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_dbg *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = sev->handle;
+ data->dst_addr = dst;
+ data->src_addr = src;
+ data->len = size;
+
+ ret = sev_issue_cmd(kvm,
+ enc ? SEV_CMD_DBG_ENCRYPT : SEV_CMD_DBG_DECRYPT,
+ data, error);
+ kfree(data);
+ return ret;
+}
+
+/*
+ * Decrypt source memory into userspace or kernel buffer. If destination buffer
+ * or len is not aligned to 16-byte boundary then it uses intermediate buffer.
+ */
+static int __sev_dbg_decrypt(struct kvm *kvm, unsigned long paddr,
+ unsigned long __user dst_uaddr,
+ unsigned long dst_kaddr, unsigned long dst_paddr,
+ int size, int *error)
+{
+ int ret, offset = 0, len = size;
+ struct page *tpage = NULL;
+
+ /*
+ * Debug command works with 16-byte aligned inputs, check if all inputs
+ * (src, dst and len) are 16-byte aligned. If one of the input is not
+ * aligned then we decrypt more than requested into a temporary buffer
+ * and copy the porition of data into destination buffer.
+ */
+ if (!IS_ALIGNED(paddr, 16) ||
+ !IS_ALIGNED(dst_paddr, 16) ||
+ !IS_ALIGNED(size, 16)) {
+ tpage = (void *)alloc_page(GFP_KERNEL);
+ if (!tpage)
+ return -ENOMEM;
+
+ dst_paddr = __sme_page_pa(tpage);
+
+ /*
+ * if source buffer is not aligned then offset will be used
+ * when copying the data from the temporary buffer into
+ * destination buffer.
+ */
+ offset = paddr & 15;
+
+ /* its safe to read more than requested size. */
+ len = round_up(size + offset, 16);
+
+ paddr = round_down(paddr, 16);
+
+ /*
+ * Cache access from the PSP are coherent with x86 but not other
+ * way around. Hence we flush the destination caches to ensure
+ * that x86 is able to see the PSP updates.
+ */
+ clflush_cache_range(page_address(tpage), PAGE_SIZE);
+ }
+
+ ret = __sev_issue_dbg_cmd(kvm, paddr, dst_paddr, len, error, false);
+
+ /*
+ * If temporary buffer is used then copy the data from temporary buffer
+ * into destination buffer.
+ */
+ if (!ret && tpage) {
+
+ /*
+ * If destination buffer is a userspace buffer then use
+ * copy_to_user otherwise memcpy.
+ */
+ if (dst_uaddr) {
+ if (copy_to_user((void __user *)(uintptr_t)dst_uaddr,
+ page_address(tpage) + offset, size))
+ ret = -EFAULT;
+ } else {
+ memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
+ }
+ }
+
+ if (tpage)
+ __free_page(tpage);
+
+ return ret;
+}
+
+static int sev_dbg_crypt(struct kvm *kvm, struct kvm_sev_cmd *argp, bool dec)
+{
+ unsigned long vaddr, vaddr_end, next_vaddr;
+ unsigned long dst_vaddr, dst_vaddr_end;
+ struct page **src_p, **dst_p;
+ struct kvm_sev_dbg debug;
+ unsigned long n;
+ int ret, size;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(&debug, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_dbg)))
+ return -EFAULT;
+
+ vaddr = debug.src_uaddr;
+ size = debug.len;
+ vaddr_end = vaddr + size;
+ dst_vaddr = debug.dst_uaddr;
+ dst_vaddr_end = dst_vaddr + size;
+
+ for (; vaddr < vaddr_end; vaddr = next_vaddr) {
+ int len, s_off, d_off;
+
+ /* lock userspace source and destination page */
+ src_p = sev_pin_memory(kvm, vaddr & PAGE_MASK, PAGE_SIZE, &n, 0);
+ if (!src_p)
+ return -EFAULT;
+
+ dst_p = sev_pin_memory(kvm, dst_vaddr & PAGE_MASK, PAGE_SIZE, &n, 1);
+ if (!dst_p) {
+ sev_unpin_memory(kvm, src_p, n);
+ return -EFAULT;
+ }
+
+ /*
+ * Cache access between te PSP and x86 are not coherent, hence we
+ * flush the caches to buffers shared with PSP to ensure that we
+ * will be able to see the PSP updates.
+ */
+ sev_clflush_pages(src_p, 1);
+ sev_clflush_pages(dst_p, 1);
+
+ /*
+ * since user buffer may not be page aligned, calculate the
+ * offset within the page.
+ */
+ s_off = vaddr & ~PAGE_MASK;
+ d_off = dst_vaddr & ~PAGE_MASK;
+ len = min_t(size_t, (PAGE_SIZE - s_off), size);
+
+ ret = __sev_dbg_decrypt(kvm,
+ __sme_page_pa(src_p[0]) + s_off,
+ dst_vaddr, 0,
+ __sme_page_pa(dst_p[0]) + d_off,
+ len, &argp->error);
+
+ sev_unpin_memory(kvm, src_p, 1);
+ sev_unpin_memory(kvm, dst_p, 1);
+
+ if (ret)
+ goto err;
+
+ next_vaddr = vaddr + len;
+ dst_vaddr = dst_vaddr + len;
+ size -= len;
+ }
+err:
+ return ret;
+}
+
+static int sev_dbg_decrypt(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ return sev_dbg_crypt(kvm, argp, true);
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6141,6 +6315,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_guest_status(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_DBG_DECRYPT: {
+ r = sev_dbg_decrypt(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 22/29] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (20 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 21/29] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 23/29] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
` (6 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command copies a plaintext into guest memory and encrypts it using
the VM encryption key. The command will be used for debug purposes
(e.g setting breakpoints through gdbserver)
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 124 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4d51ccb462db..16b338d9dc87 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6203,6 +6203,104 @@ static int __sev_dbg_decrypt(struct kvm *kvm, unsigned long paddr,
return ret;
}
+static int __sev_dbg_encrypt(struct kvm *kvm, unsigned long __user vaddr,
+ unsigned long paddr, unsigned long __user dst_vaddr,
+ unsigned long dst_paddr, int size, int *error)
+{
+ struct page *src_tpage = NULL;
+ struct page *dst_tpage = NULL;
+ int ret, len = size;
+
+ /*
+ * If source buffer is not 16-byte aligned then we copy the data from
+ * source buffer into a PAGE aligned intermediate (src_tpage) buffer
+ * and use this intermediate buffer as source buffer.
+ */
+ if (!IS_ALIGNED(vaddr, 16)) {
+ src_tpage = alloc_page(GFP_KERNEL);
+ if (!src_tpage)
+ return -ENOMEM;
+
+ if (copy_from_user(page_address(src_tpage),
+ (void __user *)(uintptr_t)vaddr, size)) {
+ __free_page(src_tpage);
+ return -EFAULT;
+ }
+ paddr = __sme_page_pa(src_tpage);
+
+ /* flush the caches to ensure that DRAM has recent contents */
+ clflush_cache_range(page_address(src_tpage), PAGE_SIZE);
+ }
+
+ /*
+ * If destination buffer or length is not 16-byte aligned then:
+ * - decrypt portion of destination buffer into intermediate buffer
+ * (dst_tpage)
+ * - copy the source data into intermediate buffer
+ * - use the intermediate buffer as source buffer
+ */
+ if (!IS_ALIGNED(dst_vaddr, 16) ||
+ !IS_ALIGNED(size, 16)) {
+ int dst_offset;
+
+ dst_tpage = alloc_page(GFP_KERNEL);
+ if (!dst_tpage) {
+ ret = -ENOMEM;
+ goto e_free;
+ }
+
+ /* decrypt destination buffer into intermediate buffer */
+ ret = __sev_dbg_decrypt(kvm,
+ round_down(dst_paddr, 16),
+ 0,
+ (unsigned long)page_address(dst_tpage),
+ __sme_page_pa(dst_tpage),
+ round_up(size, 16),
+ error);
+ if (ret)
+ goto e_free;
+
+ dst_offset = dst_paddr & 15;
+
+ /*
+ * modify the intermediate buffer with data from source buffer.
+ */
+ if (src_tpage)
+ memcpy(page_address(dst_tpage) + dst_offset,
+ page_address(src_tpage), size);
+ else {
+ if (copy_from_user(page_address(dst_tpage) + dst_offset,
+ (void __user *)(uintptr_t)vaddr, size)) {
+ ret = -EFAULT;
+ goto e_free;
+ }
+ }
+
+
+ /* use intermediate buffer as source */
+ paddr = __sme_page_pa(dst_tpage);
+
+ /*
+ * Cache accesses between x86 and PSP are not coherent. Lets
+ * flush the caches to ensure that we can get the updated contents.
+ */
+ clflush_cache_range(page_address(dst_tpage), PAGE_SIZE);
+
+ /* now we have length and destination buffer aligned */
+ dst_paddr = round_down(dst_paddr, 16);
+ len = round_up(size, 16);
+ }
+
+ ret = __sev_issue_dbg_cmd(kvm, paddr, dst_paddr, len, error, true);
+
+e_free:
+ if (src_tpage)
+ __free_page(src_tpage);
+ if (dst_tpage)
+ __free_page(dst_tpage);
+ return ret;
+}
+
static int sev_dbg_crypt(struct kvm *kvm, struct kvm_sev_cmd *argp, bool dec)
{
unsigned long vaddr, vaddr_end, next_vaddr;
@@ -6240,9 +6338,10 @@ static int sev_dbg_crypt(struct kvm *kvm, struct kvm_sev_cmd *argp, bool dec)
}
/*
- * Cache access between te PSP and x86 are not coherent, hence we
- * flush the caches to buffers shared with PSP to ensure that we
- * will be able to see the PSP updates.
+ * PSP will access the guest memory range with C=1, but hypervisor
+ * cache may still be looking the memory with C=0, lets make sure
+ * we flush the caches so that data gets accessed with correct C-bit
+ * on both PSP and x86 side.
*/
sev_clflush_pages(src_p, 1);
sev_clflush_pages(dst_p, 1);
@@ -6255,11 +6354,19 @@ static int sev_dbg_crypt(struct kvm *kvm, struct kvm_sev_cmd *argp, bool dec)
d_off = dst_vaddr & ~PAGE_MASK;
len = min_t(size_t, (PAGE_SIZE - s_off), size);
- ret = __sev_dbg_decrypt(kvm,
- __sme_page_pa(src_p[0]) + s_off,
- dst_vaddr, 0,
- __sme_page_pa(dst_p[0]) + d_off,
- len, &argp->error);
+ if (dec)
+ ret = __sev_dbg_decrypt(kvm,
+ __sme_page_pa(src_p[0]) + s_off,
+ dst_vaddr, 0,
+ __sme_page_pa(dst_p[0]) + d_off,
+ len, &argp->error);
+ else
+ ret = __sev_dbg_encrypt(kvm,
+ vaddr,
+ __sme_page_pa(src_p[0]) + s_off,
+ dst_vaddr,
+ __sme_page_pa(dst_p[0]) + d_off,
+ len, &argp->error);
sev_unpin_memory(kvm, src_p, 1);
sev_unpin_memory(kvm, dst_p, 1);
@@ -6280,6 +6387,11 @@ static int sev_dbg_decrypt(struct kvm *kvm, struct kvm_sev_cmd *argp)
return sev_dbg_crypt(kvm, argp, true);
}
+static int sev_dbg_encrypt(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ return sev_dbg_crypt(kvm, argp, false);
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6319,6 +6431,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_dbg_decrypt(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_DBG_ENCRYPT: {
+ r = sev_dbg_encrypt(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 23/29] KVM: SVM: Add support for SEV LAUNCH_SECRET command
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (21 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 22/29] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 24/29] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
` (5 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The command is used for injecting a secret into a guest memory region.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 16b338d9dc87..dadfb8e15db9 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6392,6 +6392,81 @@ static int sev_dbg_encrypt(struct kvm *kvm, struct kvm_sev_cmd *argp)
return sev_dbg_crypt(kvm, argp, false);
}
+static int sev_launch_secret(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_secret *data;
+ struct kvm_sev_launch_secret params;
+ struct page **pages;
+ void *blob, *hdr;
+ unsigned long n;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_secret)))
+ return -EFAULT;
+
+ /* verify that request has a valid guest memory region and length */
+ if (!params.guest_uaddr ||
+ !params.guest_len ||
+ (params.guest_len > SEV_FW_BLOB_MAX_SIZE))
+ return -EINVAL;
+
+ /* pin the guest memory region */
+ pages = sev_pin_memory(kvm, params.guest_uaddr, params.guest_len, &n, 1);
+ if (!pages)
+ return -ENOMEM;
+
+ /*
+ * The secret must be copied into contiguous memory region, lets verify
+ * that pinned memory pages are contiguous otherwise fail the command.
+ */
+ if (get_num_contig_pages(0, pages, n) != n) {
+ ret = -EINVAL;
+ goto e_unpin_memory;
+ }
+
+ ret = -ENOMEM;
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ goto e_unpin_memory;
+
+ /* copy the secret from userspace into a kernel buffer */
+ blob = copy_user_blob(params.trans_uaddr, params.trans_len);
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ goto e_free;
+ }
+
+ data->trans_address = __psp_pa(blob);
+ data->trans_len = params.trans_len;
+
+ /* copy the packet header from userspace into a kernel buffer */
+ hdr = copy_user_blob(params.hdr_uaddr, params.hdr_len);
+ if (IS_ERR(hdr)) {
+ ret = PTR_ERR(hdr);
+ goto e_free_blob;
+ }
+ data->trans_address = __psp_pa(blob);
+ data->trans_len = params.trans_len;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_SECRET, data, &argp->error);
+
+ kfree(hdr);
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+e_unpin_memory:
+ sev_unpin_memory(kvm, pages, n);
+
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6435,6 +6510,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_dbg_encrypt(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_SECRET: {
+ r = sev_launch_secret(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 24/29] KVM: SVM: Pin guest memory when SEV is active
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (22 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 23/29] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 25/29] KVM: X86: Add memory encryption enabled ops Brijesh Singh
` (4 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The SEV memory encryption engine uses a tweak such that two identical
plaintext pages at different location will have different ciphertexts.
So swapping or moving ciphertexts of two pages will not result in
plaintexts being swapped. Relocating (or migrating) physical backing
pages for a SEV guest will require some additional steps. The current SEV
key management spec does not provide commands to swap or migrate (move)
ciphertexts. For now, we pin the guest memory registered through
KVM_REGISTER_ENCRYPT_REGION ioctl.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 109 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 86006dcfe574..3195a8cc517d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -753,6 +753,7 @@ struct kvm_sev_info {
unsigned int handle; /* SEV firmware handle */
int fd; /* SEV device fd */
unsigned long locked; /* Number of pages locked */
+ struct list_head regions_list; /* list of registered regions */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index dadfb8e15db9..0bb62a114a20 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -330,6 +330,14 @@ static unsigned int max_sev_asid;
static unsigned long *sev_asid_bitmap;
#define __sme_page_pa(x) __sme_set(page_to_pfn(x) << PAGE_SHIFT)
+struct enc_region {
+ struct list_head list;
+ unsigned long npages;
+ struct page **pages;
+ unsigned long uaddr;
+ unsigned long size;
+};
+
static inline bool svm_sev_enabled(void)
{
return max_sev_asid;
@@ -1656,9 +1664,38 @@ static void sev_clflush_pages(struct page *pages[], unsigned long npages)
}
}
+static void __unregister_enc_region(struct kvm *kvm,
+ struct enc_region *region)
+{
+ /*
+ * The guest may change the memory encryption attribute from C=0 -> C=1
+ * or vice versa for this memory range. Lets make sure caches are
+ * flushed to ensure that guest data gets written into memory with
+ * correct C-bit.
+ */
+ sev_clflush_pages(region->pages, region->npages);
+
+ sev_unpin_memory(kvm, region->pages, region->npages);
+ list_del(®ion->list);
+ kfree(region);
+}
+
static void sev_vm_destroy(struct kvm *kvm)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct list_head *head = &sev->regions_list;
+ struct list_head *pos, *q;
+
+ /*
+ * if userspace was terminated before unregistering the memory regions
+ * then lets unpin all the registered memory.
+ */
+ if (!list_empty(head)) {
+ list_for_each_safe(pos, q, head) {
+ __unregister_enc_region(kvm,
+ list_entry(pos, struct enc_region, list));
+ }
+ }
sev_deactivate_handle(kvm);
sev_decommission_handle(kvm);
@@ -5741,6 +5778,7 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
sev->active = true;
sev->asid = asid;
+ INIT_LIST_HEAD(&sev->regions_list);
return 0;
e_shutdown:
sev_firmware_exit();
@@ -6524,6 +6562,75 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
return r;
}
+static int svm_register_enc_region(struct kvm *kvm,
+ struct kvm_enc_region *range)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct enc_region *region;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ region = kzalloc(sizeof(*region), GFP_KERNEL);
+ if (!region)
+ return -ENOMEM;
+
+ region->pages = sev_pin_memory(kvm, range->addr, range->size, ®ion->npages, 1);
+ if (!region->pages)
+ goto e_free;
+
+ /*
+ * The guest may change the memory encryption attribute from C=0 -> C=1
+ * or vice versa for this memory range. Lets make sure caches are
+ * flushed to ensure that guest data gets written into memory with
+ * correct C-bit.
+ */
+ sev_clflush_pages(region->pages, region->npages);
+
+ region->uaddr = range->addr;
+ region->size = range->size;
+ list_add_tail(®ion->list, &sev->regions_list);
+ return 0;
+
+e_free:
+ kfree(region);
+ return 1;
+}
+
+static struct enc_region *
+find_enc_region(struct kvm *kvm, struct kvm_enc_region *range)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct list_head *head = &sev->regions_list;
+ struct enc_region *i;
+
+ list_for_each_entry(i, head, list) {
+ if (i->uaddr == range->addr &&
+ i->size == range->size)
+ return i;
+ }
+
+ return NULL;
+}
+
+
+static int svm_unregister_enc_region(struct kvm *kvm,
+ struct kvm_enc_region *range)
+{
+ struct enc_region *region;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ region = find_enc_region(kvm, range);
+ if (!region)
+ return -EINVAL;
+
+ __unregister_enc_region(kvm, region);
+
+ return 0;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -6636,6 +6743,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.setup_mce = svm_setup_mce,
.mem_enc_op = svm_mem_enc_op,
+ .mem_enc_register_region = svm_register_enc_region,
+ .mem_enc_unregister_region = svm_unregister_enc_region,
};
static int __init svm_init(void)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 25/29] KVM: X86: Add memory encryption enabled ops
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (23 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 24/29] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 26/29] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
` (3 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
Extend kvm_x86_ops to add mem_enc_enabled() ops. The ops can be used to
check if memory encryption is enabled for a given VCPU.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3195a8cc517d..cad9672fbe8c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1076,6 +1076,7 @@ struct kvm_x86_ops {
int (*mem_enc_op)(struct kvm *kvm, void __user *argp);
int (*mem_enc_register_region)(struct kvm *kvm, struct kvm_enc_region *argp);
int (*mem_enc_unregister_region)(struct kvm *kvm, struct kvm_enc_region *argp);
+ bool (*mem_enc_enabled)(struct kvm_vcpu *vcpu);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0bb62a114a20..208c8abf0bbd 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6631,6 +6631,11 @@ static int svm_unregister_enc_region(struct kvm *kvm,
return 0;
}
+static bool mem_enc_enabled(struct kvm_vcpu *vcpu)
+{
+ return to_svm(vcpu)->vmcb->control.nested_ctl & SVM_NESTED_CTL_SEV_ENABLE;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -6745,6 +6750,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.mem_enc_op = svm_mem_enc_op,
.mem_enc_register_region = svm_register_enc_region,
.mem_enc_unregister_region = svm_unregister_enc_region,
+ .mem_enc_enabled = mem_enc_enabled
};
static int __init svm_init(void)
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 26/29] KVM: SVM: Clear C-bit from the page fault address
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (24 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 25/29] KVM: X86: Add memory encryption enabled ops Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 27/29] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
` (2 subsequent siblings)
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
When SEV is active, on #NPF the page fault address will contain the C-bit.
We must clear the C-bit before handling the fault.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 208c8abf0bbd..b9906cb59238 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2436,7 +2436,7 @@ static void svm_set_dr7(struct kvm_vcpu *vcpu, unsigned long value)
static int pf_interception(struct vcpu_svm *svm)
{
- u64 fault_address = svm->vmcb->control.exit_info_2;
+ u64 fault_address = __sme_clr(svm->vmcb->control.exit_info_2);
u64 error_code = svm->vmcb->control.exit_info_1;
return kvm_handle_page_fault(&svm->vcpu, error_code, fault_address,
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 27/29] KVM: SVM: Do not install #UD intercept when SEV is enabled
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (25 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 26/29] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 28/29] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
On #UD, x86_emulate_instruction() fetches the data from guest memory and
decodes the instruction bytes to assist further. When SEV is enabled, the
instruction bytes will be encrypted using the guest-specific key and the
hypervisor will no longer able to fetch the instruction bytes to assist
UD handling. By not installing intercept we let the guest receive and
handle #UD.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b9906cb59238..d997f63c765d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1437,8 +1437,10 @@ static void init_vmcb(struct vcpu_svm *svm)
svm->vmcb->control.int_ctl |= V_GIF_ENABLE_MASK;
}
- if (sev_guest(svm->vcpu.kvm))
+ if (sev_guest(svm->vcpu.kvm)) {
svm->vmcb->control.nested_ctl |= SVM_NESTED_CTL_SEV_ENABLE;
+ clr_exception_intercept(svm, UD_VECTOR);
+ }
mark_all_dirty(svm->vmcb);
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 28/29] KVM: X86: Restart the guest when insn_len is zero and SEV is enabled
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (26 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 27/29] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-19 20:46 ` [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
28 siblings, 0 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
On AMD platforms, under certain conditions insn_len may be zero on #NPF.
This can happen if a guest gets a page-fault on data access but the HW
table walker is not able to read the instruction page (e.g instruction
page is not present in memory).
Typically, when insn_len is zero, x86_emulate_instruction() walks the
guest page table and fetches the instruction bytes from guest memory.
When SEV is enabled, the guest memory is encrypted with guest-specific
key hence hypervisor will not able to fetch the instruction bytes.
In those cases we simply restart the guest.
I have encountered this issue when running kernbench inside the guest.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/mmu.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index eca30c1eb1d9..2bc0fe84aca2 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4953,6 +4953,23 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u64 error_code,
if (mmio_info_in_cache(vcpu, cr2, direct))
emulation_type = 0;
emulate:
+ /*
+ * On AMD platforms, under certain conditions insn_len may be zero on #NPF.
+ * This can happen if a guest gets a page-fault on data access but the HW
+ * table walker is not able to read the instruction page (e.g instruction
+ * page is not present in memory).
+ *
+ * Typically, when insn_len is zero, x86_emulate_instruction() walks the
+ * guest page table and fetches the instruction bytes from guest memory.
+ * When SEV is enabled, the guest memory is encrypted with guest-specific
+ * key hence hypervisor will not able to fetch the instruction bytes.
+ * In those cases we simply restart the guest.
+ */
+ if (unlikely(!insn_len) &&
+ kvm_x86_ops->mem_enc_enabled &&
+ kvm_x86_ops->mem_enc_enabled(vcpu))
+ return 1;
+
er = x86_emulate_instruction(vcpu, cr2, emulation_type, insn, insn_len);
switch (er) {
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV
2017-09-19 20:45 [Part2 PATCH v4 00/29] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (27 preceding siblings ...)
2017-09-19 20:46 ` [Part2 PATCH v4 28/29] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
@ 2017-09-19 20:46 ` Brijesh Singh
2017-09-22 20:37 ` kbuild test robot
2017-09-22 22:18 ` kbuild test robot
28 siblings, 2 replies; 56+ messages in thread
From: Brijesh Singh @ 2017-09-19 20:46 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
The config option can be used to enable SEV support on AMD Processors.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/Kconfig | 8 ++++++++
arch/x86/kvm/svm.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 3ea624452f93..06d3d221a503 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -79,6 +79,14 @@ config KVM_AMD
To compile this as a module, choose M here: the module
will be called kvm-amd.
+config KVM_AMD_SEV
+ def_bool y
+ bool "AMD Secure Encrypted Virtualization (SEV) support"
+ depends on KVM_AMD
+ select CRYPTO_DEV_SP_PSP
+ ---help---
+ Provides support for Encrypted VMs on AMD processors.
+
config KVM_MMU_AUDIT
bool "Audit KVM MMU"
depends on KVM && TRACEPOINTS
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d997f63c765d..f9878efb808a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1143,7 +1143,8 @@ static __init int svm_hardware_setup(void)
kvm_tsc_scaling_ratio_frac_bits = 32;
}
- if (boot_cpu_has(X86_FEATURE_SEV))
+ if (boot_cpu_has(X86_FEATURE_SEV) &&
+ IS_ENABLED(CONFIG_KVM_AMD_SEV))
sev_hardware_setup();
if (nested) {
--
2.9.5
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV
2017-09-19 20:46 ` [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
@ 2017-09-22 20:37 ` kbuild test robot
2017-09-22 22:18 ` kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 20:37 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
Hi Brijesh,
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.14-rc1 next-20170922]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/x86-Secure-Encrypted-Virtualization-AMD/20170923-033600
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: i386-randconfig-x015-201738 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
warning: (KVM_AMD_SEV) selects CRYPTO_DEV_SP_PSP which has unmet direct dependencies (CRYPTO && CRYPTO_HW && CRYPTO_DEV_CCP && CRYPTO_DEV_CCP_DD)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25138 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV
2017-09-19 20:46 ` [Part2 PATCH v4 29/29] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
2017-09-22 20:37 ` kbuild test robot
@ 2017-09-22 22:18 ` kbuild test robot
1 sibling, 0 replies; 56+ messages in thread
From: kbuild test robot @ 2017-09-22 22:18 UTC (permalink / raw)
To: Brijesh Singh
Cc: kbuild-all, linux-kernel, kvm, Brijesh Singh, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky, x86
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
Hi Brijesh,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.14-rc1 next-20170922]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/x86-Secure-Encrypted-Virtualization-AMD/20170923-033600
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "sev_platform_shutdown" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_guest_decommission" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_platform_init" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_platform_status" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_guest_deactivate" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_guest_df_flush" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_issue_cmd_external_user" [arch/x86/kvm/kvm-amd.ko] undefined!
>> ERROR: "sev_guest_activate" [arch/x86/kvm/kvm-amd.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40036 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread