All of lore.kernel.org
 help / color / mirror / Atom feed
* [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD)
@ 2017-10-20  2:33 Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
                   ` (39 more replies)
  0 siblings, 40 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini,
	Radim
	Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, Herbert Xu,
	David S . Miller, Gary Hook, x86, linux-kernel, linux-crypto

This part of Secure Encryted Virtualization (SEV) patch series focuses on KVM
changes required to create and manage SEV guests.

SEV is an extension to the AMD-V architecture which supports running encrypted
virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have their
pages (code and data) secured such that only the guest itself has access to
unencrypted version. Each encrypted VM is associated with a unique encryption key;
if its data is accessed to a different entity using a different key the encrypted
guest's data will be incorrectly decrypted, leading to unintelligible data.
This security model ensures that hypervisor will no longer able to inspect or
alter any guest code or data.

The key management of this feature is handled by a separate processor known as
the AMD Secure Processor (AMD-SP) which is present on AMD SOCs. The SEV Key
Management Specification (see below) provides a set of commands which can be
used by hypervisor to load virtual machine keys through the AMD-SP driver.

The patch series adds a new ioctl in KVM driver (KVM_MEMORY_ENCRYPTION_OP). The
ioctl will be used by qemu to issue SEV guest-specific commands defined in Key
Management Specification.

The following links provide additional details:

AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer's Manual:
    http://support.amd.com/TechDocs/24593.pdf
    SME is section 7.10
    SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf

KVM Forum Presentation:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf

SEV Guest BIOS support:
  SEV support has been interated into EDKII/OVMF BIOS
  https://github.com/tianocore/edk2

SEV Part 1 patch series: https://marc.info/?l=kvm&m=150816835817641&w=2

--
The series is based on kvm/master commit : cc9085b68753 (Merge branch 'kvm-ppc-fixes')

Complete tree is available at:
repo: https://github.com/codomania/kvm.git
branch: sev-v6-p2

TODO:
* Add SEV guest migration command support

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: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Gary Hook <gary.hook@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-crypto@vger.kernel.org

Changes since v5:
 * split the PSP driver support into multiple patches
 * multiple improvements from Boris
 * remove mem_enc_enabled() ops

Changes since v4:
 * Fixes to address kbuild robot errors
 * Add 'sev' module params to allow enable/disable SEV feature
 * Update documentation
 * Multiple fixes to address v4 feedbacks
 * Some coding style changes to address checkpatch reports

Changes since v3:
 * Re-design the PSP interface support patch
 * Rename the ioctls based on the feedbacks
 * Improve documentation
 * Fix i386 build issues
 * Add LAUNCH_SECRET command
 * Add new Kconfig option to enable SEV support
 * Changes to address v3 feedbacks.

Changes since v2:
 * Add KVM_MEMORY_ENCRYPT_REGISTER/UNREGISTER_RAM ioct to register encrypted
   memory ranges (recommend by Paolo)
 * Extend kvm_x86_ops to provide new memory_encryption_enabled ops
 * Enhance DEBUG DECRYPT/ENCRYPT commands to work with more than one page \
                (recommended by Paolo)
 * Optimize LAUNCH_UPDATE command to reduce the number of calls to AMD-SP driver
 * Changes to address v2 feedbacks


Borislav Petkov (1):
  crypto: ccp: Build the AMD secure processor driver only with AMD CPU
    support

Brijesh Singh (34):
  Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization
    (SEV)
  KVM: SVM: Prepare to reserve asid for SEV guest
  KVM: X86: Extend CPUID range to include new leaf
  KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl
  KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl
  crypto: ccp: Define SEV userspace ioctl and command id
  crypto: ccp: Define SEV key management command id
  crypto: ccp: Add Platform Security Processor (PSP) device support
  crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
  crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
  crypto: ccp: Implement SEV_PEK_GEN ioctl command
  crypto: ccp: Implement SEV_PDH_GEN ioctl command
  crypto: ccp: Implement SEV_PEK_CSR ioctl command
  crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
  crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
  KVM: X86: Add CONFIG_KVM_AMD_SEV
  KVM: SVM: Add sev module_param
  KVM: SVM: Reserve ASID range for SEV guest
  KVM: Define SEV key management command id
  KVM: SVM: Add KVM_SEV_INIT command
  KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled
  KVM: SVM: Add support for KVM_SEV_LAUNCH_START command
  KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command
  KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command
  KVM: SVM: Add support for SEV LAUNCH_FINISH command
  KVM: SVM: Add support for SEV GUEST_STATUS command
  KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  KVM: SVM: Add support for SEV DEBUG_ENCRYPT command
  KVM: SVM: Add support for SEV LAUNCH_SECRET command
  KVM: SVM: Pin guest memory when SEV is active
  KVM: SVM: Clear C-bit from the page fault address
  KVM: SVM: Do not install #UD intercept when SEV is enabled
  KVM: X86: Restart the guest when insn_len is zero and SEV is enabled

Tom Lendacky (3):
  x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
  kvm: svm: prepare for new bit definition in nested_ctl
  kvm: svm: Add SEV feature definitions to KVM

 Documentation/virtual/kvm/00-INDEX                 |    3 +
 .../virtual/kvm/amd-memory-encryption.txt          |  201 ++++
 Documentation/virtual/kvm/api.txt                  |   50 +
 arch/x86/include/asm/cpufeatures.h                 |    1 +
 arch/x86/include/asm/kvm_host.h                    |   15 +
 arch/x86/include/asm/msr-index.h                   |    2 +
 arch/x86/include/asm/svm.h                         |    3 +
 arch/x86/kernel/cpu/amd.c                          |   66 +-
 arch/x86/kernel/cpu/scattered.c                    |    1 +
 arch/x86/kvm/Kconfig                               |   10 +
 arch/x86/kvm/cpuid.c                               |    2 +-
 arch/x86/kvm/mmu.c                                 |   10 +
 arch/x86/kvm/svm.c                                 | 1167 +++++++++++++++++++-
 arch/x86/kvm/x86.c                                 |   30 +
 drivers/crypto/ccp/Kconfig                         |   12 +
 drivers/crypto/ccp/Makefile                        |    1 +
 drivers/crypto/ccp/psp-dev.c                       |  736 ++++++++++++
 drivers/crypto/ccp/psp-dev.h                       |   80 ++
 drivers/crypto/ccp/sp-dev.c                        |   26 +
 drivers/crypto/ccp/sp-dev.h                        |   24 +-
 drivers/crypto/ccp/sp-pci.c                        |   52 +
 include/linux/psp-sev.h                            |  657 +++++++++++
 include/uapi/linux/kvm.h                           |   90 ++
 include/uapi/linux/psp-sev.h                       |  113 ++
 24 files changed, 3322 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/virtual/kvm/amd-memory-encryption.txt
 create mode 100644 drivers/crypto/ccp/psp-dev.c
 create mode 100644 drivers/crypto/ccp/psp-dev.h
 create mode 100644 include/linux/psp-sev.h
 create mode 100644 include/uapi/linux/psp-sev.h

-- 
2.9.5

^ permalink raw reply	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20 13:18   ` Jonathan Corbet
  2017-10-20  2:33 ` [Part2 PATCH v6 02/38] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
                   ` (38 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Jonathan Corbet, Borislav Petkov, Tom Lendacky, x86,
	linux-kernel

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>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 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

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

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 02/38] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 03/38] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
                   ` (37 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, x86, linux-kernel, 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>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 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 d58184b7cd44..c1234aa0550c 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] 120+ messages in thread

* [Part2 PATCH v6 03/38] kvm: svm: prepare for new bit definition in nested_ctl
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 02/38] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 04/38] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
                   ` (36 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, x86, linux-kernel, 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] 120+ messages in thread

* [Part2 PATCH v6 04/38] kvm: svm: Add SEV feature definitions to KVM
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (2 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 03/38] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 05/38] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
                   ` (35 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, x86, linux-kernel, 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] 120+ messages in thread

* [Part2 PATCH v6 05/38] KVM: SVM: Prepare to reserve asid for SEV guest
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (3 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 04/38] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 06/38] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
                   ` (34 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

Currently, ASID allocation start at 1. Add a svm_vcpu_data.min_asid
which allows supplying a dynamic start ASID.

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: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 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] 120+ messages in thread

* [Part2 PATCH v6 06/38] KVM: X86: Extend CPUID range to include new leaf
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (4 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 05/38] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 07/38] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
                   ` (33 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 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 2c3a3c88596c..fab5b1b7fc63 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5149,6 +5149,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] 120+ messages in thread

* [Part2 PATCH v6 07/38] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (5 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 06/38] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl Brijesh Singh
                   ` (32 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

If the hardware supports memory encryption then the
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>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 Documentation/virtual/kvm/api.txt | 16 ++++++++++++++++
 arch/x86/include/asm/kvm_host.h   |  2 ++
 arch/x86/kvm/x86.c                |  6 ++++++
 include/uapi/linux/kvm.h          |  2 ++
 4 files changed, 26 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e63a35fafef0..fcafdae1739e 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3390,6 +3390,22 @@ 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_ENCRYPT_OP
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: an opaque platform specific structure (in/out)
+Returns: 0 on success; -1 on error
+
+If the platform supports creating encrypted VMs then this ioctl can be used
+for issuing platform-specific memory encryption commands to manage those
+encrypted VMs.
+
+Currently, this ioctl is used for issuing Secure Encrypted Virtualization
+(SEV) commands on AMD Processors. The SEV commands are defined in
+Documentation/virtual/kvm/amd-memory-encryption.txt.
+
 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 03869eb7fcd6..4c365eb23080 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4270,6 +4270,12 @@ long kvm_arch_vm_ioctl(struct file *filp,
 		r = kvm_vm_ioctl_enable_cap(kvm, &cap);
 		break;
 	}
+	case KVM_MEMORY_ENCRYPT_OP: {
+		r = -ENOTTY;
+		if (kvm_x86_ops->mem_enc_op)
+			r = kvm_x86_ops->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..4a39d99c5f99 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_ENCRYPT_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] 120+ messages in thread

* [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (6 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 07/38] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20 15:00   ` Borislav Petkov
  2017-10-20  2:33 ` [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
                   ` (31 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REG_REGION
and KVM_MEMORY_ENCRYPT_UNREG_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 | 34 ++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/kvm_host.h   |  2 ++
 arch/x86/kvm/x86.c                | 24 ++++++++++++++++++++++++
 include/uapi/linux/kvm.h          |  8 ++++++++
 4 files changed, 68 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fcafdae1739e..365b6e2c8be5 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3406,6 +3406,40 @@ Currently, this ioctl is used for issuing Secure Encrypted Virtualization
 (SEV) commands on AMD Processors. The SEV commands are defined in
 Documentation/virtual/kvm/amd-memory-encryption.txt.
 
+4.110 KVM_MEMORY_ENCRYPT_REG_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 a guest memory region which may
+contain encrypted data (e.g. guest RAM, SMRAM etc).
+
+It is used in the SEV-enabled guest. When encryption is enabled, a guest
+memory region may contain encrypted data. The SEV memory encryption
+engine uses a tweak such that two identical plaintext pages, each at
+different locations will have differing ciphertexts. So swapping or
+moving ciphertext of those pages will not result in plaintext being
+swapped. So relocating (or migrating) physical backing pages for the SEV
+guest will require some additional steps.
+
+Note: The current SEV key management spec does not provide commands to
+swap or migrate (move) ciphertext pages. Hence, for now we pin the guest
+memory region registered with the ioctl.
+
+4.111 KVM_MEMORY_ENCRYPT_UNREG_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 guest memory region registered
+with KVM_MEMORY_ENCRYPT_REG_REGION ioctl above.
+
 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..3af074452b2b 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_reg_region)(struct kvm *kvm, struct kvm_enc_region *argp);
+	int (*mem_enc_unreg_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 4c365eb23080..d4e2c61cb6b7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4276,6 +4276,30 @@ long kvm_arch_vm_ioctl(struct file *filp,
 			r = kvm_x86_ops->mem_enc_op(kvm, argp);
 		break;
 	}
+	case KVM_MEMORY_ENCRYPT_REG_REGION: {
+		struct kvm_enc_region region;
+
+		r = -EFAULT;
+		if (copy_from_user(&region, argp, sizeof(region)))
+			goto out;
+
+		r = -ENOTTY;
+		if (kvm_x86_ops->mem_enc_reg_region)
+			r = kvm_x86_ops->mem_enc_reg_region(kvm, &region);
+		break;
+	}
+	case KVM_MEMORY_ENCRYPT_UNREG_REGION: {
+		struct kvm_enc_region region;
+
+		r = -EFAULT;
+		if (copy_from_user(&region, argp, sizeof(region)))
+			goto out;
+
+		r = -ENOTTY;
+		if (kvm_x86_ops->mem_enc_unreg_region)
+			r = kvm_x86_ops->mem_enc_unreg_region(kvm, &region);
+		break;
+	}
 	default:
 		r = -ENOTTY;
 	}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 4a39d99c5f99..1f9f26a8e111 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1359,6 +1359,14 @@ struct kvm_s390_ucas_mapping {
 /* Memory Encryption Commands */
 #define KVM_MEMORY_ENCRYPT_OP      _IOWR(KVMIO, 0xba, unsigned long)
 
+struct kvm_enc_region {
+	__u64 addr;
+	__u64 size;
+};
+
+#define KVM_MEMORY_ENCRYPT_REG_REGION    _IOR(KVMIO, 0xbb, struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREG_REGION  _IOR(KVMIO, 0xbc, struct kvm_enc_region)
+
 #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] 120+ messages in thread

* [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (7 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-24 18:40   ` Gary R Hook
  2017-10-20  2:33 ` [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
                   ` (30 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Borislav Petkov, Brijesh Singh, Tom Lendacky, Gary Hook,
	Herbert Xu, David S. Miller, linux-crypto

From: Borislav Petkov <bp@suse.de>

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>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 6d626606b9c5..9c84f9838931 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.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (8 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-24 18:40   ` Gary R Hook
  2017-10-20  2:33 ` [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management " Brijesh Singh
                   ` (29 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

Add a include file which defines the ioctl and command id used for
issuing SEV platform management specific commands.

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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 include/uapi/linux/psp-sev.h | 113 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 include/uapi/linux/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..1dd98ba4ff22
--- /dev/null
+++ b/include/uapi/linux/psp-sev.h
@@ -0,0 +1,113 @@
+/*
+ * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
+ * platform management commands.
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * SEV spec 0.14 is available at:
+ * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+ *
+ * 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_FACTORY_RESET = 0,
+	SEV_PLATFORM_STATUS,
+	SEV_PEK_GEN,
+	SEV_PEK_CSR,
+	SEV_PDH_GEN,
+	SEV_PDH_CERT_EXPORT,
+	SEV_PEK_CERT_IMPORT,
+
+	SEV_MAX,
+};
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @flags: 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 */
+	__u32 flags;				/* Out */
+	__u8 build;				/* Out */
+	__u32 guest_count;			/* Out */
+} __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 */
+} __packed;
+
+/**
+ * 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 */
+} __packed;
+
+/**
+ * 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 */
+} __packed;
+
+/**
+ * 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 */
+} __packed;
+
+#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] 120+ messages in thread

* [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management command id
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (9 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-24 18:40   ` Gary R Hook
  2017-10-20  2:33 ` [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
                   ` (28 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

Define Secure Encrypted Virtualization (SEV) key management command id
and structure. The command definition is available in SEV KM [1] spec
0.14.

[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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 include/linux/psp-sev.h | 494 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 494 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..15bda519538e
--- /dev/null
+++ b/include/linux/psp-sev.h
@@ -0,0 +1,494 @@
+/*
+ * AMD Secure Encrypted Virtualization (SEV) driver interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * SEV spec 0.14 is available at:
+ * http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
+ *
+ * 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__
+
+#include <uapi/linux/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 sev_data_init {
+	u32 flags;			/* In */
+	u32 reserved;			/* In */
+	u64 tmr_address;		/* In */
+	u32 tmr_len;			/* In */
+} __packed;
+
+/**
+ * struct sev_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @len: len of certificate
+ */
+struct sev_data_pek_csr {
+	u64 address;				/* In */
+	u32 len;				/* In/Out */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * struct sev_data_decommission - DECOMMISSION command parameters
+ *
+ * @handle: handle of the VM to decommission
+ */
+struct sev_data_decommission {
+	u32 handle;				/* In */
+} __packed;
+
+/**
+ * struct sev_data_activate - ACTIVATE command parameters
+ *
+ * @handle: handle of the VM to activate
+ * @asid: asid assigned to the VM
+ */
+struct sev_data_activate {
+	u32 handle;				/* In */
+	u32 asid;				/* In */
+} __packed;
+
+/**
+ * struct sev_data_deactivate - DEACTIVATE command parameters
+ *
+ * @handle: handle of the VM to deactivate
+ */
+struct sev_data_deactivate {
+	u32 handle;				/* In */
+} __packed;
+
+/**
+ * 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 sev_data_guest_status {
+	u32 handle;				/* In */
+	u32 policy;				/* Out */
+	u32 asid;				/* Out */
+	u8 state;				/* Out */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 sev_data_launch_update_data {
+	u32 handle;				/* In */
+	u32 reserved;
+	u64 address;				/* In */
+	u32 len;				/* In */
+} __packed;
+
+/**
+ * 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 sev_data_launch_update_vmsa {
+	u32 handle;				/* In */
+	u32 reserved;
+	u64 address;				/* In */
+	u32 len;				/* In */
+} __packed;
+
+/**
+ * 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 sev_data_launch_measure {
+	u32 handle;				/* In */
+	u32 reserved;
+	u64 address;				/* In */
+	u32 len;				/* In/Out */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * struct sev_data_launch_finish - LAUNCH_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct sev_data_launch_finish {
+	u32 handle;				/* In */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * struct sev_data_send_finish - SEND_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct sev_data_send_finish {
+	u32 handle;				/* In */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * 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 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 */
+} __packed;
+
+/**
+ * struct sev_data_receive_finish - RECEIVE_FINISH command parameters
+ *
+ * @handle: handle of the VM to finish
+ */
+struct sev_data_receive_finish {
+	u32 handle;				/* In */
+} __packed;
+
+/**
+ * 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 sev_data_dbg {
+	u32 handle;				/* In */
+	u32 reserved;
+	u64 src_addr;				/* In */
+	u64 dst_addr;				/* In */
+	u32 len;				/* In */
+} __packed;
+
+#endif	/* __PSP_SEV_H__ */
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (10 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-24 18:40   ` Gary R Hook
  2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
                   ` (27 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The Platform Security Processor (PSP) is part of the AMD Secure
Processor (AMD-SP) functionality. 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 third-party trusted applications.

Note that the key management functionality provided by the SEV firmware
can be used outside of the kvm-amd driver hence it doesn't need to
depend 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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 drivers/crypto/ccp/Kconfig   |  11 +++++
 drivers/crypto/ccp/Makefile  |   1 +
 drivers/crypto/ccp/psp-dev.c | 105 +++++++++++++++++++++++++++++++++++++++++++
 drivers/crypto/ccp/psp-dev.h |  59 ++++++++++++++++++++++++
 drivers/crypto/ccp/sp-dev.c  |  26 +++++++++++
 drivers/crypto/ccp/sp-dev.h  |  24 +++++++++-
 drivers/crypto/ccp/sp-pci.c  |  52 +++++++++++++++++++++
 7 files changed, 277 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 9c84f9838931..b9dfae47aefd 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -33,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 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 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..b5789f878560
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -0,0 +1,105 @@
+/*
+ * 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"
+
+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..55b7808367c3
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -0,0 +1,59 @@
+/*
+ * 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;
+};
+
+#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..909cf3e436b4 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,17 @@ struct ccp_vdata {
 	const unsigned int offset;
 	const unsigned int rsamax;
 };
+
+struct psp_vdata {
+	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 +73,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 +112,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 +140,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..f5f43c50698a 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) {
@@ -225,6 +268,12 @@ static int sp_pci_resume(struct pci_dev *pdev)
 }
 #endif
 
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+static const struct psp_vdata psp_entry = {
+	.offset = 0x10500,
+};
+#endif
+
 static const struct sp_dev_vdata dev_vdata[] = {
 	{
 		.bar = 2,
@@ -237,6 +286,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] 120+ messages in thread

* [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (11 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23  7:34     ` Borislav Petkov
                     ` (2 more replies)
  2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
                   ` (26 subsequent siblings)
  39 siblings, 3 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the 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 API to communicate with the SEV firmware. The API can be
   used by the hypervisor to create encryption context for a SEV guest.

 - a 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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 drivers/crypto/ccp/psp-dev.c | 306 +++++++++++++++++++++++++++++++++++++++++++
 drivers/crypto/ccp/psp-dev.h |  21 +++
 include/linux/psp-sev.h      | 159 ++++++++++++++++++++++
 3 files changed, 486 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index b5789f878560..e9966d5fc6c4 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -26,6 +26,14 @@
 #include "sp-dev.h"
 #include "psp-dev.h"
 
+#define DEVICE_NAME	"sev"
+
+static DEFINE_MUTEX(sev_cmd_mutex);
+static DEFINE_MUTEX(fw_init_mutex);
+
+static struct sev_misc_dev *sev_misc_dev;
+static int fw_init_count;
+
 static struct psp_device *psp_alloc_struct(struct sp_device *sp)
 {
 	struct device *dev = sp->dev;
@@ -45,9 +53,298 @@ static struct psp_device *psp_alloc_struct(struct sp_device *sp)
 
 static irqreturn_t psp_irq_handler(int irq, void *data)
 {
+	struct psp_device *psp = data;
+	unsigned int status;
+	int reg;
+
+	/* Read the interrupt status: */
+	status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
+
+	/* Check if it is command completion: */
+	if (!(status & BIT(PSP_CMD_COMPLETE_REG)))
+		goto done;
+
+	/* Check if it is 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);
+	}
+
+done:
+	/* Clear the interrupt status by writing the same value we read. */
+	iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
+
 	return IRQ_HANDLED;
 }
 
+static void 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);
+}
+
+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_user_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_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:		return sizeof(struct sev_data_dbg);
+	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_FINISH:		return sizeof(struct sev_data_receive_finish);
+	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_LAUNCH_UPDATE_SECRET:	return sizeof(struct sev_data_launch_secret);
+	default:				return 0;
+	}
+
+	return 0;
+}
+
+static int sev_do_cmd(int cmd, void *data, int *psp_ret)
+{
+	unsigned int phys_lsb, phys_msb;
+	unsigned int reg, ret = 0;
+	struct psp_device *psp;
+	struct sp_device *sp;
+
+	sp = sp_get_psp_master_device();
+	if (!sp)
+		return -ENODEV;
+
+	psp = sp->psp_data;
+	if (!psp)
+		return -ENODEV;
+
+	/* Get the physical address of the command buffer */
+	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 |= PSP_CMDRESP_IOC;
+	iowrite32(reg, psp->io_regs + PSP_CMDRESP);
+
+	/* wait for command completion */
+	sev_wait_cmd_ioc(psp, &reg);
+
+	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;
+	}
+
+	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 long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
+{
+	return -ENOTTY;
+}
+
+static const struct file_operations sev_fops = {
+	.owner	= THIS_MODULE,
+	.unlocked_ioctl = sev_ioctl,
+};
+
+static int __sev_platform_init(struct sev_data_init *data, int *error)
+{
+	int rc = 0;
+
+	mutex_lock(&fw_init_mutex);
+
+	if (!fw_init_count) {
+		rc = sev_do_cmd(SEV_CMD_INIT, data, error);
+		if (rc)
+			goto unlock;
+	}
+
+	fw_init_count++;
+
+unlock:
+	mutex_unlock(&fw_init_mutex);
+	return rc;
+
+}
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+	struct sev_data_init *input = NULL;
+	int rc;
+
+	if (!data) {
+		input = kzalloc(sizeof(*input), GFP_KERNEL);
+		if (!input)
+			return -ENOMEM;
+
+		data = input;
+	}
+
+	rc = __sev_platform_init(data, error);
+
+	kfree(input);
+	return rc;
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+int sev_platform_shutdown(int *error)
+{
+	int rc = 0;
+
+	mutex_lock(&fw_init_mutex);
+
+	if (!fw_init_count)
+		goto unlock;
+
+	if (fw_init_count == 1) {
+		rc = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, error);
+		if (rc)
+			goto unlock;
+	}
+
+	fw_init_count--;
+
+unlock:
+	mutex_unlock(&fw_init_mutex);
+	return rc;
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_user_data_status *data, int *error)
+{
+	return sev_do_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_do_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_do_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_do_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_do_cmd(SEV_CMD_DECOMMISSION, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_decommission);
+
+int sev_guest_df_flush(int *error)
+{
+	return sev_do_cmd(SEV_CMD_DF_FLUSH, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_df_flush);
+
+static int sev_ops_init(struct psp_device *psp)
+{
+	struct device *dev = psp->dev;
+	int ret;
+
+	/*
+	 * SEV feature support can be detected on multiple devices but the SEV
+	 * FW commands must be issued on the master. During probe, we do not
+	 * know the master hence we create /dev/sev on the first device probe.
+	 * sev_do_cmd() finds the right master device to which to issue the
+	 * command to the firmware.
+	 */
+	if (!sev_misc_dev) {
+		struct miscdevice *misc;
+
+		sev_misc_dev = devm_kzalloc(dev, sizeof(*sev_misc_dev), GFP_KERNEL);
+		if (!sev_misc_dev)
+			return -ENOMEM;
+
+		misc = &sev_misc_dev->misc;
+		misc->minor = MISC_DYNAMIC_MINOR;
+		misc->name = DEVICE_NAME;
+		misc->fops = &sev_fops;
+
+		ret = misc_register(misc);
+		if (ret)
+			return ret;
+
+		kref_init(&sev_misc_dev->refcount);
+	} else {
+		kref_get(&sev_misc_dev->refcount);
+	}
+
+	init_waitqueue_head(&psp->sev_int_queue);
+	psp->sev_misc = sev_misc_dev;
+	dev_info(dev, "registered SEV device\n");
+
+	return 0;
+}
+
+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 kref *ref)
+{
+	struct sev_misc_dev *sev_dev = container_of(ref, struct sev_misc_dev, refcount);
+
+	misc_deregister(&sev_dev->misc);
+}
+
 int psp_dev_init(struct sp_device *sp)
 {
 	struct device *dev = sp->dev;
@@ -84,11 +381,17 @@ int psp_dev_init(struct sp_device *sp)
 	if (sp->set_psp_master_device)
 		sp->set_psp_master_device(sp);
 
+	ret = sev_init(psp);
+	if (ret)
+		goto e_irq;
+
 	/* Enable interrupt */
 	iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
 
 	return 0;
 
+e_irq:
+	sp_free_psp_irq(psp->sp, psp);
 e_err:
 	sp->psp_data = NULL;
 
@@ -101,5 +404,8 @@ void psp_dev_destroy(struct sp_device *sp)
 {
 	struct psp_device *psp = sp->psp_data;
 
+	if (psp->sev_misc)
+		kref_put(&sev_misc_dev->refcount, sev_exit);
+
 	sp_free_psp_irq(sp, psp);
 }
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 55b7808367c3..13467c484f6d 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
 
@@ -44,6 +56,11 @@
 
 #define MAX_PSP_NAME_LEN		16
 
+struct sev_misc_dev {
+	struct kref refcount;
+	struct miscdevice misc;
+};
+
 struct psp_device {
 	struct list_head entry;
 
@@ -54,6 +71,10 @@ struct psp_device {
 	struct sp_device *sp;
 
 	void __iomem *io_regs;
+
+	unsigned int sev_int_rcvd;
+	wait_queue_head_t sev_int_queue;
+	struct sev_misc_dev *sev_misc;
 };
 
 #endif /* __PSP_DEV_H */
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 15bda519538e..21511419bfe6 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -491,4 +491,163 @@ struct sev_data_dbg {
 	u32 len;				/* In */
 } __packed;
 
+#ifdef 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_user_data_status *status, int *error);
+
+/**
+ * sev_issue_cmd_external_user - issue SEV command by other driver with a file
+ * handle.
+ *
+ * This function can be used by other drivers to issue a SEV command on
+ * behalf of userspace. The caller must pass a valid SEV file descriptor
+ * so that we know that it 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_user_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_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; }
+
+static inline int
+sev_issue_cmd_external_user(struct file *filep,
+			    unsigned int id, void *data, int *error)
+{
+	return -ENODEV;
+}
+
+#endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
+
 #endif	/* __PSP_SEV_H__ */
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (12 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23  7:42     ` Borislav Petkov
                     ` (2 more replies)
  2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
                   ` (25 subsequent siblings)
  39 siblings, 3 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_FACTORY_RESET command can be used by the platform owner to
reset the non-volatile SEV related data. The command is defined in
SEV spec section 5.4

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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 drivers/crypto/ccp/psp-dev.c | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e9966d5fc6c4..99f3761206da 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -176,7 +176,33 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
 
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
-	return -ENOTTY;
+	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_MAX)
+		return -EINVAL;
+
+	switch (input.cmd) {
+
+	case SEV_FACTORY_RESET:
+		ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
+		ret = -EFAULT;
+out:
+	return ret;
 }
 
 static const struct file_operations sev_fops = {
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (13 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23  8:48   ` Borislav Petkov
                     ` (2 more replies)
  2017-10-20  2:33 ` [Part2 PATCH v6 16/38] " Brijesh Singh
                   ` (24 subsequent siblings)
  39 siblings, 3 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PLATFORM_STATUS command can be used by the platform owner to
get the current status of the platform. The command is defined in
SEV spec section 5.5.

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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 drivers/crypto/ccp/psp-dev.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 99f3761206da..5c921b36bc23 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -174,6 +174,27 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
 	return ret;
 }
 
+static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_status *data;
+	int ret;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
+	if (ret)
+		goto e_free;
+
+	if (copy_to_user((void __user *)argp->data, data, sizeof(*data)))
+		ret = -EFAULT;
+
+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;
@@ -194,6 +215,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_FACTORY_RESET:
 		ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
 		break;
+	case SEV_PLATFORM_STATUS:
+		ret = sev_ioctl_do_platform_status(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (14 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23  9:32   ` Borislav Petkov
  2017-10-23 21:55   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
                   ` (23 subsequent siblings)
  39 siblings, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.

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 | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 5c921b36bc23..1d7212da25a5 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -195,6 +195,24 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
+{
+	int ret, err;
+
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		return ret;
+
+	ret = sev_do_cmd(cmd, 0, &argp->error);
+
+	if (sev_platform_shutdown(&err)) {
+		argp->error = err;
+		ret = -EIO;
+	}
+
+	return ret;
+}
+
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
 	void __user *argp = (void __user *)arg;
@@ -218,6 +236,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PLATFORM_STATUS:
 		ret = sev_ioctl_do_platform_status(&input);
 		break;
+	case SEV_PEK_GEN:
+		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (15 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 16/38] " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23 12:35   ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
  2017-10-20  2:33 ` [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
                   ` (22 subsequent siblings)
  39 siblings, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PDH_GEN command is used to re-generate the Platform
Diffie-Hellman (PDH) key. The command is defined in SEV spec section
5.6.

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 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 1d7212da25a5..d9771d104eea 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -239,6 +239,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PEK_GEN:
 		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
 		break;
+	case SEV_PDH_GEN:
+		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (16 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23 12:49     ` Borislav Petkov
  2017-10-23 22:10   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
                   ` (21 subsequent siblings)
  39 siblings, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.

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 | 69 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d9771d104eea..26a365c9b0e0 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -213,6 +213,72 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_csr input;
+	struct sev_data_pek_csr *data;
+	void *blob = NULL;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* userspace wants to query CSR length */
+	if (!input.address || !input.length)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the CSR blob */
+	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
+	    input.length > SEV_FW_BLOB_MAX_SIZE) {
+		ret = -EFAULT;
+		goto e_free;
+	}
+
+	blob = kmalloc(input.length, GFP_KERNEL);
+	if (!blob) {
+		ret = -ENOMEM;
+		goto e_free;
+	}
+
+	data->address = __psp_pa(blob);
+	data->len = input.length;
+
+cmd:
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_blob;
+
+	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+	/*
+	 * If we query the CSR length, FW responded with expected data
+	 */
+	input.length = data->len;
+
+	if (blob) {
+		if (copy_to_user((void __user *)input.address, blob, input.length))
+			ret = -EFAULT;
+	}
+
+	if (sev_platform_shutdown(&err)) {
+		ret = -EIO;
+		argp->error = err;
+	}
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
+		ret = -EFAULT;
+
+e_free_blob:
+	kfree(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;
@@ -242,6 +308,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PDH_GEN:
 		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
 		break;
+	case SEV_PEK_CSR:
+		ret = sev_ioctl_do_pek_csr(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (17 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23 22:14   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
                   ` (20 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK
certificate. The command is defined in SEV spec section 5.8.

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 | 83 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/psp-sev.h      |  4 +++
 2 files changed, 87 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 26a365c9b0e0..89242d4d1067 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -279,6 +279,86 @@ static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+void *psp_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 (!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);
+}
+EXPORT_SYMBOL_GPL(psp_copy_user_blob);
+
+static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_cert_import input;
+	struct sev_data_pek_cert_import *data;
+	void *pek_blob, *oca_blob;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* copy PEK certificate blobs from userspace */
+	pek_blob = psp_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 = psp_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_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_oca;
+
+	ret = sev_do_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+
+	if (sev_platform_shutdown(&err)) {
+		ret = -EIO;
+		argp->error = err;
+	}
+
+e_free_oca:
+	kfree(oca_blob);
+e_free_pek:
+	kfree(pek_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;
@@ -311,6 +391,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PEK_CSR:
 		ret = sev_ioctl_do_pek_csr(&input);
 		break;
+	case SEV_PEK_CERT_IMPORT:
+		ret = sev_ioctl_do_pek_cert_import(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 21511419bfe6..f9113d315cf8 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -620,6 +620,8 @@ int sev_guest_df_flush(int *error);
  */
 int sev_guest_decommission(struct sev_data_decommission *data, int *error);
 
+void *psp_copy_user_blob(u64 __user uaddr, u32 len);
+
 #else	/* !CONFIG_CRYPTO_DEV_SP_PSP */
 
 static inline int
@@ -648,6 +650,8 @@ sev_issue_cmd_external_user(struct file *filep,
 	return -ENODEV;
 }
 
+static inline void *psp_copy_user_blob(u64 __user uaddr, u32 len) { return ERR_PTR(-EINVAL); }
+
 #endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
 
 #endif	/* __PSP_SEV_H__ */
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (18 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-23 22:19   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 21/38] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
                   ` (19 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, linux-kernel

The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its
certificate chain. The command is defined in SEV spec section 5.10.

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 | 99 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 89242d4d1067..ad4f67bc0d71 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -359,6 +359,102 @@ static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pdh_cert_export(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pdh_cert_export input;
+	void *pdh_blob = NULL, *cert_blob = NULL;
+	struct sev_data_pdh_cert_export *data;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* Userspace wants to query the certificate length */
+	if (!input.pdh_cert_address || !input.pdh_cert_len ||
+	    !input.cert_chain_address || !input.cert_chain_address)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the PDH blob */
+	if (!access_ok(VERIFY_WRITE, input.pdh_cert_address, input.pdh_cert_len) ||
+	    (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE)) {
+		ret = -EFAULT;
+		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;
+
+	/* allocate a physically contiguous buffer to store the cert chain blob */
+	if (!access_ok(VERIFY_WRITE, input.cert_chain_address, input.cert_chain_len) ||
+	    (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE)) {
+		ret = -EFAULT;
+		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;
+
+cmd:
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_cert;
+
+	ret = sev_do_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+
+	/*
+	 * If we query the length, FW responded with expected data
+	 */
+	input.cert_chain_len = data->cert_chain_len;
+	input.pdh_cert_len = data->pdh_cert_len;
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
+		ret = -EFAULT;
+
+	if (sev_platform_shutdown(&err)) {
+		ret = -EIO;
+		argp->error = err;
+		goto e_free_cert;
+	}
+
+	if (pdh_blob) {
+		if (copy_to_user((void __user *)input.pdh_cert_address,
+				 pdh_blob, input.pdh_cert_len)) {
+			ret = -EFAULT;
+			goto e_free_cert;
+		}
+	}
+
+	if (cert_blob) {
+		if (copy_to_user((void __user *)input.cert_chain_address,
+				 cert_blob, input.cert_chain_len))
+			ret = -EFAULT;
+	}
+
+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;
@@ -394,6 +490,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PEK_CERT_IMPORT:
 		ret = sev_ioctl_do_pek_cert_import(&input);
 		break;
+	case SEV_PDH_CERT_EXPORT:
+		ret = sev_ioctl_do_pdh_cert_export(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 21/38] KVM: X86: Add CONFIG_KVM_AMD_SEV
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (19 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 22/38] KVM: SVM: Add sev module_param Brijesh Singh
                   ` (18 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kvm/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 3c48bc8bf08c..86273a0f981a 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -80,6 +80,16 @@ 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 && X86_64
+	select CRYPTO_DEV_CCP
+	select CRYPTO_DEV_CCP_DD
+	select CRYPTO_DEV_SP_PSP
+	---help---
+	Provides support for launching Encrypted VMs on AMD processors.
+
 config KVM_MMU_AUDIT
 	bool "Audit KVM MMU"
 	depends on KVM && TRACEPOINTS
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 22/38] KVM: SVM: Add sev module_param
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (20 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 21/38] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-20  2:33 ` [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
                   ` (17 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The module parameter can be used to control the SEV feature support.

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/svm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index fab5b1b7fc63..be2e98c01b22 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -284,6 +284,10 @@ module_param(vls, int, 0444);
 static int vgif = true;
 module_param(vgif, int, 0444);
 
+/* enable/disable SEV support */
+static int sev = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
+module_param(sev, int, 0444);
+
 static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
 static void svm_flush_tlb(struct kvm_vcpu *vcpu);
 static void svm_complete_interrupts(struct vcpu_svm *svm);
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (21 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 22/38] KVM: SVM: Add sev module_param Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-27 20:23   ` Borislav Petkov
  2017-10-20  2:33 ` [Part2 PATCH v6 24/38] KVM: Define SEV key management command id Brijesh Singh
                   ` (16 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

A SEV-enabled guest must use ASIDs from the defined subset, while non-SEV
guests can use the remaining ASID range. The range of 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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 arch/x86/kvm/svm.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index be2e98c01b22..d4b62536e305 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -323,6 +323,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;
@@ -787,7 +789,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);
@@ -1054,6 +1056,15 @@ static int avic_ga_log_notifier(u32 ga_tag)
 	return 0;
 }
 
+/*
+ * Get the maximum number of encrypted guests:
+ *  Fn8001_001F[ECX][31:0]: Number of supported guests.
+ */
+static __init void sev_hardware_setup(void)
+{
+	max_sev_asid = cpuid_ecx(0x8000001F);
+}
+
 static __init int svm_hardware_setup(void)
 {
 	int cpu;
@@ -1084,6 +1095,16 @@ static __init int svm_hardware_setup(void)
 		kvm_tsc_scaling_ratio_frac_bits = 32;
 	}
 
+	if (sev) {
+		if (boot_cpu_has(X86_FEATURE_SEV) &&
+		    IS_ENABLED(CONFIG_KVM_AMD_SEV)) {
+			sev_hardware_setup();
+			pr_info("SEV supported\n");
+		} else {
+			sev = false;
+		}
+	}
+
 	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] 120+ messages in thread

* [Part2 PATCH v6 24/38] KVM: Define SEV key management command id
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (22 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
@ 2017-10-20  2:33 ` Brijesh Singh
  2017-10-27 20:23   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
                   ` (15 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:33 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

Define Secure Encrypted Virtualization (SEV) key management command id
and structure. The command definition is available in SEV KM [1] spec
0.14 (http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf)
and Documentation/virtual/kvm/amd-memory-encryption.txt.

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>
---
 .../virtual/kvm/amd-memory-encryption.txt          | 163 +++++++++++++++++++++
 include/uapi/linux/kvm.h                           |  80 ++++++++++
 2 files changed, 243 insertions(+)

diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
index 26472b4cdbaf..1ec5517f2948 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.txt
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -36,3 +36,166 @@ setting the SEV bit before executing VMRUN.
 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.
+
+SEV Key Management
+------------------
+
+The SEV guest key management is handled by a separate processor called the AMD
+Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a secure
+key management interface to perform common hypervisor activities such as
+encrypting bootstrap code, snapshot, migrating and debugging the guest. For more
+information, see the SEV Key Management spec:
+http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+
+KVM implements the following commands to support common lifecycle events of SEV
+guests, such as launching, running, snapshotting, migrating and decommissioning.
+
+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 {
+	__u32 handle;		/* if zero then firmware creates a new handle */
+	__u32 policy;		/* guest's policy */
+
+	__u64 dh_uaddr;		/* userspace address pointing to the guest owner's PDH key */
+	__u32 dh_len;
+
+	__u64 session_addr;	/* userspace address which points to the guest session information */
+	__u32 session_len;
+};
+
+On success, the 'handle' field contains 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 a memory region. It also
+calculates a measurement of the memory contents. The measurement is a signature
+of the memory contents that can be sent to the guest owner as an attestation
+that the memory was encrypted correctly by the firmware.
+
+struct kvm_sev_launch_update {
+	__u64 uaddr;		/* userspace address to be encrypted (must be 16-byte aligned) */
+	__u32 len;		/* length of the data to be encrypted (must be 16-byte aligned) */
+};
+
+For more details, see SEV spec Section 6.3.
+
+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 command. The guest owner may
+wait to provide the guest with confidential information until it can verify the
+measurement. Since the guest owner knows the initial contents of the guest at
+boot, the measurement can be verified by comparing it to what the guest owner
+expects.
+
+struct kvm_sev_launch_measure {
+	__u64 uaddr;		/* where to copy the measurement */
+	__u32 len;		/* length of measurement blob */
+};
+
+For more details on the measurement verification flow, see SEV spec Section 6.4.
+
+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 a
+SEV-enabled guest.
+
+struct kvm_sev_guest_status {
+	__u32 handle;		/* guest handle */
+	__u32 policy;		/* guest policy */
+	__u8 state;		/* guest state (see enum below) */
+};
+
+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 {
+	__u64 src_uaddr;	/* userspace address of data to decrypt */
+	__u64 dst_uaddr;	/* userspace address of destination */
+	__u32 len;		/* length of memory region to decrypt */
+};
+
+The command returns an error if the 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 {
+	__u64 src_uaddr;	/* userspace address of data to encrypt */
+	__u64 dst_uaddr;	/* userspace address of destination */
+	__u32 len;		/* length of memory region to encrypt */
+};
+
+The command returns an error if the guest policy does not allow debugging.
+
+9. KVM_SEV_LAUNCH_SECRET
+
+Parameters (in): struct kvm_sev_launch_secret
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject secret
+data after the measurement has been validated by the guest owner.
+
+struct kvm_sev_launch_secret {
+	__u64 hdr_uaddr;	/* userspace address containing the packet header */
+	__u32 hdr_len;
+
+	__u64 guest_uaddr;	/* the guest memory region where the secret should be injected */
+	__u32 guest_len;
+
+	__u64 trans_uaddr;	/* the hypervisor memory region which contains the secret */
+	__u32 trans_len;
+};
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 1f9f26a8e111..027153971c97 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1367,6 +1367,86 @@ struct kvm_enc_region {
 #define KVM_MEMORY_ENCRYPT_REG_REGION    _IOR(KVMIO, 0xbb, struct kvm_enc_region)
 #define KVM_MEMORY_ENCRYPT_UNREG_REGION  _IOR(KVMIO, 0xbc, struct kvm_enc_region)
 
+/* 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_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_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] 120+ messages in thread

* [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (23 preceding siblings ...)
  2017-10-20  2:33 ` [Part2 PATCH v6 24/38] KVM: Define SEV key management command id Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:24   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 26/38] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
                   ` (14 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The command initializes the SEV platform context 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              | 132 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 138 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3af074452b2b..b8837cff22ec 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 d4b62536e305..d496063ccd78 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>
@@ -324,6 +326,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)
 {
@@ -1063,6 +1078,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)
@@ -1167,10 +1187,18 @@ static __init int svm_hardware_setup(void)
 	return r;
 }
 
+static __exit void sev_hardware_unsetup(void)
+{
+	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);
 
@@ -1361,6 +1389,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);
@@ -1443,6 +1474,28 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
 	return 0;
 }
 
+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)
+{
+	if (!sev_guest(kvm))
+		return;
+
+	sev_platform_shutdown(NULL);
+	sev_asid_free(kvm);
+}
+
 static void avic_vm_destroy(struct kvm *kvm)
 {
 	unsigned long flags;
@@ -1461,6 +1514,12 @@ 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);
+	sev_vm_destroy(kvm);
+}
+
 static int avic_vm_init(struct kvm *kvm)
 {
 	unsigned long flags;
@@ -5427,6 +5486,75 @@ 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_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+	struct kvm_sev_info *sev = &kvm->arch.sev_info;
+	int asid, ret;
+
+	ret = sev_platform_init(NULL, &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_platform_shutdown(&argp->error);
+	return ret;
+}
+
+static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
+{
+	struct kvm_sev_cmd sev_cmd;
+	int r;
+
+	if (!svm_sev_enabled())
+		return -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:
+		r = -EINVAL;
+		goto out;
+	}
+
+	if (copy_to_user(argp, &sev_cmd, sizeof(struct kvm_sev_cmd)))
+		r = -EFAULT;
+
+out:
+	mutex_unlock(&kvm->lock);
+	return r;
+}
+
 static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
 	.cpu_has_kvm_support = has_svm,
 	.disabled_by_bios = is_disabled,
@@ -5443,7 +5571,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,
@@ -5537,6 +5665,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] 120+ messages in thread

* [Part2 PATCH v6 26/38] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (24 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 27/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
                   ` (13 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

SEV hardware uses ASIDs to associate a memory encryption key with a
guest VM. During guest creation, a SEV VM uses the 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>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 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 d496063ccd78..2f10bb47359c 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;
 };
 
 /*
@@ -340,6 +343,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;
@@ -550,6 +560,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);
@@ -863,6 +876,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);
 }
@@ -876,11 +890,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;
@@ -1477,7 +1498,8 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
 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;
@@ -1485,6 +1507,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)
@@ -4419,12 +4446,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] 120+ messages in thread

* [Part2 PATCH v6 27/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (25 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 26/38] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
                   ` (12 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The KVM_SEV_LAUNCH_START command is used to create a memory encryption
context within the SEV firmware. In order to do so, the guest owner
should provide the guest's policy, its public Diffie-Hellman (PDH) key
and session information. The command implements the LAUNCH_START flow
defined in SEV spec Section 6.2.

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              | 153 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 155 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b8837cff22ec..f2654486b9a6 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 2f10bb47359c..3bc0d4013aa6 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1514,11 +1514,45 @@ static void sev_asid_free(struct kvm *kvm)
 	}
 }
 
+static void sev_unbind_asid(struct kvm *kvm, unsigned int handle)
+{
+	struct sev_data_decommission *decommission;
+	struct sev_data_deactivate *data;
+
+	if (!handle)
+		return;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return;
+
+	/* deactivate handle */
+	data->handle = handle;
+	sev_guest_deactivate(data, NULL);
+
+	wbinvd_on_all_cpus();
+	sev_guest_df_flush(NULL);
+	kfree(data);
+
+	decommission = kzalloc(sizeof(*decommission), GFP_KERNEL);
+	if (!decommission)
+		return;
+
+	/* decommission handle */
+	decommission->handle = handle;
+	sev_guest_decommission(decommission, NULL);
+
+	kfree(decommission);
+}
+
 static void sev_vm_destroy(struct kvm *kvm)
 {
+	struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
 	if (!sev_guest(kvm))
 		return;
 
+	sev_unbind_asid(kvm, sev->handle);
 	sev_platform_shutdown(NULL);
 	sev_asid_free(kvm);
 }
@@ -5579,6 +5613,122 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
 	return ret;
 }
 
+static int sev_bind_asid(struct kvm *kvm, unsigned int handle, int *error)
+{
+	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;
+
+	/* activate ASID on the given handle */
+	data->handle = handle;
+	data->asid   = asid;
+	ret = sev_guest_activate(data, error);
+	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 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(&params, (void __user *)(uintptr_t)argp->data, sizeof(params)))
+		return -EFAULT;
+
+	start = kzalloc(sizeof(*start), GFP_KERNEL);
+	if (!start)
+		return -ENOMEM;
+
+	dh_blob = NULL;
+	if (params.dh_uaddr) {
+		dh_blob = psp_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 = psp_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;
+
+	/* Bind ASID to this guest */
+	ret = sev_bind_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, &params, sizeof(params))) {
+		sev_unbind_asid(kvm, start->handle);
+		ret = -EFAULT;
+		goto e_free_session;
+	}
+
+	sev->handle = start->handle;
+	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;
@@ -5596,6 +5746,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_INIT:
 		r = sev_guest_init(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_START:
+		r = sev_launch_start(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (26 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 27/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:24   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
                   ` (11 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 f2654486b9a6..924ce807c76c 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 pages_locked; /* Number of pages locked */
 };
 
 struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3bc0d4013aa6..7f13bb8a7078 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>
@@ -330,6 +332,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)
 {
@@ -1545,6 +1548,83 @@ static void sev_unbind_asid(struct kvm *kvm, unsigned int handle)
 	kfree(decommission);
 }
 
+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, npinned, 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->pages_locked + npages;
+	lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+	if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
+		pr_err("SEV: %lu locked pages exceed the lock limit of %lu.\n", locked, lock_limit);
+		return NULL;
+	}
+
+	/* Avoid using vmalloc for smaller buffers. */
+	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. */
+	npinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0, pages);
+	if (npinned != npages) {
+		pr_err("SEV: Failure locking %lu pages.\n", npages);
+		goto err;
+	}
+
+	*n = npages;
+	sev->pages_locked = locked;
+
+	return pages;
+
+err:
+	if (npinned > 0)
+		release_pages(pages, npinned, 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;
+
+	release_pages(pages, npages, 0);
+	kvfree(pages);
+	sev->pages_locked -= npages;
+}
+
+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;
@@ -5638,7 +5718,7 @@ static int sev_bind_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;
@@ -5653,6 +5733,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 int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
 {
 	struct kvm_sev_info *sev = &kvm->arch.sev_info;
@@ -5700,7 +5787,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;
 
@@ -5729,6 +5816,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(&params, (void __user *)(uintptr_t)argp->data, sizeof(params)))
+		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;
+	}
+
+	/*
+	 * The LAUNCH_UPDATE command will perform in-place encryption of the
+	 * memory content (i.e it will write the same memory region with C=1).
+	 * It's possible that the cache may contain the data with C=0, i.e.,
+	 * unencrypted so invalidate it first.
+	 */
+	sev_clflush_pages(inpages, npages);
+
+	for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i += pages) {
+		int offset, len;
+
+		/*
+		 * If the user buffer is not 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;
@@ -5749,6 +5933,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_LAUNCH_START:
 		r = sev_launch_start(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_UPDATE_DATA:
+		r = sev_launch_update_data(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (27 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:24   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
                   ` (10 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The command is used to retrieve the measurement of contents encrypted
through the KVM_SEV_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 | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7f13bb8a7078..3ab2d4ae11ea 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5913,6 +5913,66 @@ 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(&params, (void __user *)(uintptr_t)argp->data, sizeof(params)))
+		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;
+		}
+
+		if (!access_ok(VERIFY_WRITE, params.uaddr, params.len)) {
+			ret = -EFAULT;
+			goto e_free;
+		}
+
+		ret = -ENOMEM;
+		blob = kmalloc(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);
+
+	params.len = data->len;
+	if (copy_to_user((void __user *)(uintptr_t)argp->data, &params, sizeof(params))) {
+		ret = -EFAULT;
+		goto e_free_blob;
+	}
+
+	if (blob) {
+		if (copy_to_user((void __user *)(uintptr_t)params.uaddr, blob, params.len))
+			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;
@@ -5936,6 +5996,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_LAUNCH_UPDATE_DATA:
 		r = sev_launch_update_data(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_MEASURE:
+		r = sev_launch_measure(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (28 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:25   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
                   ` (9 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3ab2d4ae11ea..5ac290b845b9 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5973,6 +5973,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;
@@ -5999,6 +6019,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_LAUNCH_MEASURE:
 		r = sev_launch_measure(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_FINISH:
+		r = sev_launch_finish(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (29 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:25   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
                   ` (8 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The command is used for querying the SEV guest information.

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 | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5ac290b845b9..83a4d0406a4b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5993,6 +5993,36 @@ 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, &params, sizeof(params)))
+		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;
@@ -6022,6 +6052,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_LAUNCH_FINISH:
 		r = sev_launch_finish(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_GUEST_STATUS:
+		r = sev_guest_status(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (30 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-27 20:25   ` Borislav Petkov
  2017-10-20  2:34 ` [Part2 PATCH v6 33/38] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
                   ` (7 subsequent siblings)
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 179 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 83a4d0406a4b..f19c4fb2fdc8 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6023,6 +6023,182 @@ 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);
+
+		/*
+		 * The temporary buffer may have mapping with C=0 or C=1 on x86
+		 * side but PSP will will write the memory region with C=0.
+		 * Lets make sure x86 cache for this memory range is flushed so
+		 * that we can see the recent contents after the command
+		 * completes.
+		 */
+		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(debug)))
+		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;
+		}
+
+		/*
+		 * Depending on the operation type (encrypt or decrypt), PSP
+		 * will access the source and destination buffer with C=0 or
+		 * C=1. Lets make sure that caches are flushed so that data gets
+		 * accessed with correct C-bit.
+		 */
+		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;
@@ -6055,6 +6231,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_GUEST_STATUS:
 		r = sev_guest_status(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_DBG_DECRYPT:
+		r = sev_dbg_decrypt(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 33/38] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (31 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 34/38] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
                   ` (6 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 | 119 ++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 114 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f19c4fb2fdc8..a91eae7b9c80 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6122,6 +6122,99 @@ 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);
+
+		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);
+
+		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;
@@ -6174,11 +6267,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);
@@ -6199,6 +6300,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;
@@ -6234,6 +6340,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_DBG_DECRYPT:
 		r = sev_dbg_decrypt(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_DBG_ENCRYPT:
+		r = sev_dbg_encrypt(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 34/38] KVM: SVM: Add support for SEV LAUNCH_SECRET command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (32 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 33/38] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 35/38] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
                   ` (5 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The command is used for injecting a secret into the 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 | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a91eae7b9c80..c72ec87868bb 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6305,6 +6305,74 @@ 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(&params, (void __user *)(uintptr_t)argp->data, sizeof(params)))
+		return -EFAULT;
+
+	/* 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.
+	 */
+	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 = psp_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 = psp_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;
@@ -6343,6 +6411,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_DBG_ENCRYPT:
 		r = sev_dbg_encrypt(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_SECRET:
+		r = sev_launch_secret(kvm, &sev_cmd);
+		break;
 	default:
 		r = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 35/38] KVM: SVM: Pin guest memory when SEV is active
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (33 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 34/38] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 36/38] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
                   ` (4 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

The SEV memory encryption engine uses a tweak such that two identical
plaintext pages at different location will have different ciphertext.
So swapping or moving ciphertext of two pages will not result in
plaintext 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)
ciphertext pages. For now, we pin the guest memory registered through
KVM_MEMORY_ENCRYPT_REGISTER_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              | 112 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 113 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 924ce807c76c..0458f494f5e4 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 pages_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 c72ec87868bb..af218e11f23d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -334,6 +334,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;
@@ -1625,13 +1633,42 @@ 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(&region->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 (!sev_guest(kvm))
 		return;
 
+	/*
+	 * 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_unbind_asid(kvm, sev->handle);
 	sev_platform_shutdown(NULL);
 	sev_asid_free(kvm);
@@ -5685,6 +5722,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;
 
@@ -6427,6 +6465,78 @@ 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;
+	int ret = 0;
+
+	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, &region->npages, 1);
+	if (!region->pages) {
+		ret = -ENOMEM;
+		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(&region->list, &sev->regions_list);
+	return ret;
+
+e_free:
+	kfree(region);
+	return ret;
+}
+
+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,
@@ -6539,6 +6649,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_reg_region = svm_register_enc_region,
+	.mem_enc_unreg_region = svm_unregister_enc_region,
 };
 
 static int __init svm_init(void)
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6 36/38] KVM: SVM: Clear C-bit from the page fault address
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (34 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 35/38] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 37/38] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
                   ` (3 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 af218e11f23d..e1eaaf2fbe80 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2403,7 +2403,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] 120+ messages in thread

* [Part2 PATCH v6 37/38] KVM: SVM: Do not install #UD intercept when SEV is enabled
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (35 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 36/38] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-20  2:34 ` [Part2 PATCH v6 38/38] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
                   ` (2 subsequent siblings)
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 e1eaaf2fbe80..cd0a94e12c2a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1421,8 +1421,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] 120+ messages in thread

* [Part2 PATCH v6 38/38] KVM: X86: Restart the guest when insn_len is zero and SEV is enabled
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (36 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 37/38] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
@ 2017-10-20  2:34 ` Brijesh Singh
  2017-10-23 22:07 ` [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command Brijesh Singh
  2017-10-24 12:14 ` [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-20  2:34 UTC (permalink / raw)
  To: kvm
  Cc: bp, Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Borislav Petkov, Tom Lendacky, x86, linux-kernel

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 | 10 ++++++++++
 arch/x86/kvm/svm.c |  3 ++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7a69cf053711..0d4776b855bb 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4954,6 +4954,16 @@ 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). In those cases we simply restart the
+	 * guest.
+	 */
+	if (unlikely(insn && !insn_len))
+		return 1;
+
 	er = x86_emulate_instruction(vcpu, cr2, emulation_type, insn, insn_len);
 
 	switch (er) {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index cd0a94e12c2a..d6e62d41545d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2409,7 +2409,8 @@ static int pf_interception(struct vcpu_svm *svm)
 	u64 error_code = svm->vmcb->control.exit_info_1;
 
 	return kvm_handle_page_fault(&svm->vcpu, error_code, fault_address,
-			svm->vmcb->control.insn_bytes,
+			static_cpu_has(X86_FEATURE_DECODEASSISTS) ?
+			svm->vmcb->control.insn_bytes : NULL,
 			svm->vmcb->control.insn_len, !npt_enabled);
 }
 
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
  2017-10-20  2:33 ` [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
@ 2017-10-20 13:18   ` Jonathan Corbet
  2017-10-23 22:40     ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Jonathan Corbet @ 2017-10-20 13:18 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, bp, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Tom Lendacky, x86, linux-kernel

On Thu, 19 Oct 2017 21:33:36 -0500
Brijesh Singh <brijesh.singh@amd.com> wrote:

> Create a Documentation entry to describe the AMD Secure Encrypted
> Virtualization (SEV) feature.

A couple of quick notes...

 - This is describing an x86 subarchitecture feature, so it seems to me
   that Documentation/x86 would be a more logical place for it.  Yes, KVM
   can use this feature, but it's not a KVM feature and there might be
   something else that takes advantage of it too.

 - Any chance of getting it formatted as RST?  It's almost there already.

Beyond that, the document obviously falls far short of what one would
have to know to use SEV; probably filling all that in would make it long
indeed.

Thanks,

jon

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl
  2017-10-20  2:33 ` [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl Brijesh Singh
@ 2017-10-20 15:00   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-20 15:00 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:33:43PM -0500, Brijesh Singh wrote:
> If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REG_REGION
> and KVM_MEMORY_ENCRYPT_UNREG_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 | 34 ++++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/kvm_host.h   |  2 ++
>  arch/x86/kvm/x86.c                | 24 ++++++++++++++++++++++++
>  include/uapi/linux/kvm.h          |  8 ++++++++
>  4 files changed, 68 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>
Improvements-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-10-23  7:34     ` Borislav Petkov
  2017-10-23  9:20     ` Borislav Petkov
  2017-10-29 20:48   ` [Part2 PATCH v6.1 16/38] " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  7:34 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:48PM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the 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 API to communicate with the SEV firmware. The API can be
>    used by the hypervisor to create encryption context for a SEV guest.
> 
>  - a userspace IOCTL to manage the platform certificates.

Just minor cleanups:

---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e9966d5fc6c4..f9a9a6e6ab99 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -31,7 +31,7 @@
 static DEFINE_MUTEX(sev_cmd_mutex);
 static DEFINE_MUTEX(fw_init_mutex);
 
-static struct sev_misc_dev *sev_misc_dev;
+static struct sev_misc_dev *misc_dev;
 static int fw_init_count;
 
 static struct psp_device *psp_alloc_struct(struct sp_device *sp)
@@ -299,14 +299,14 @@ static int sev_ops_init(struct psp_device *psp)
 	 * sev_do_cmd() finds the right master device to which to issue the
 	 * command to the firmware.
 	 */
-	if (!sev_misc_dev) {
+	if (!misc_dev) {
 		struct miscdevice *misc;
 
-		sev_misc_dev = devm_kzalloc(dev, sizeof(*sev_misc_dev), GFP_KERNEL);
-		if (!sev_misc_dev)
+		misc_dev = devm_kzalloc(dev, sizeof(*misc_dev), GFP_KERNEL);
+		if (!misc_dev)
 			return -ENOMEM;
 
-		misc = &sev_misc_dev->misc;
+		misc = &misc_dev->misc;
 		misc->minor = MISC_DYNAMIC_MINOR;
 		misc->name = DEVICE_NAME;
 		misc->fops = &sev_fops;
@@ -315,13 +315,13 @@ static int sev_ops_init(struct psp_device *psp)
 		if (ret)
 			return ret;
 
-		kref_init(&sev_misc_dev->refcount);
+		kref_init(&misc_dev->refcount);
 	} else {
-		kref_get(&sev_misc_dev->refcount);
+		kref_get(&misc_dev->refcount);
 	}
 
 	init_waitqueue_head(&psp->sev_int_queue);
-	psp->sev_misc = sev_misc_dev;
+	psp->sev_misc = misc_dev;
 	dev_info(dev, "registered SEV device\n");
 
 	return 0;
@@ -340,9 +340,9 @@ static int sev_init(struct psp_device *psp)
 
 static void sev_exit(struct kref *ref)
 {
-	struct sev_misc_dev *sev_dev = container_of(ref, struct sev_misc_dev, refcount);
+	struct sev_misc_dev *misc_dev = container_of(ref, struct sev_misc_dev, refcount);
 
-	misc_deregister(&sev_dev->misc);
+	misc_deregister(&misc_dev->misc);
 }
 
 int psp_dev_init(struct sp_device *sp)
@@ -405,7 +405,7 @@ void psp_dev_destroy(struct sp_device *sp)
 	struct psp_device *psp = sp->psp_data;
 
 	if (psp->sev_misc)
-		kref_put(&sev_misc_dev->refcount, sev_exit);
+		kref_put(&misc_dev->refcount, sev_exit);
 
 	sp_free_psp_irq(sp, psp);
 }
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 21511419bfe6..eac850a97610 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -525,7 +525,7 @@ int sev_platform_shutdown(int *error);
 /**
  * sev_platform_status - perform SEV PLATFORM_STATUS command
  *
- * @init: sev_data_status structure to be processed
+ * @status: sev_user_data_status structure to be processed
  * @error: SEV command return code
  *
  * Returns:

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
@ 2017-10-23  7:34     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  7:34 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:48PM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the 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 API to communicate with the SEV firmware. The API can be
>    used by the hypervisor to create encryption context for a SEV guest.
> 
>  - a userspace IOCTL to manage the platform certificates.

Just minor cleanups:

---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e9966d5fc6c4..f9a9a6e6ab99 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -31,7 +31,7 @@
 static DEFINE_MUTEX(sev_cmd_mutex);
 static DEFINE_MUTEX(fw_init_mutex);
 
-static struct sev_misc_dev *sev_misc_dev;
+static struct sev_misc_dev *misc_dev;
 static int fw_init_count;
 
 static struct psp_device *psp_alloc_struct(struct sp_device *sp)
@@ -299,14 +299,14 @@ static int sev_ops_init(struct psp_device *psp)
 	 * sev_do_cmd() finds the right master device to which to issue the
 	 * command to the firmware.
 	 */
-	if (!sev_misc_dev) {
+	if (!misc_dev) {
 		struct miscdevice *misc;
 
-		sev_misc_dev = devm_kzalloc(dev, sizeof(*sev_misc_dev), GFP_KERNEL);
-		if (!sev_misc_dev)
+		misc_dev = devm_kzalloc(dev, sizeof(*misc_dev), GFP_KERNEL);
+		if (!misc_dev)
 			return -ENOMEM;
 
-		misc = &sev_misc_dev->misc;
+		misc = &misc_dev->misc;
 		misc->minor = MISC_DYNAMIC_MINOR;
 		misc->name = DEVICE_NAME;
 		misc->fops = &sev_fops;
@@ -315,13 +315,13 @@ static int sev_ops_init(struct psp_device *psp)
 		if (ret)
 			return ret;
 
-		kref_init(&sev_misc_dev->refcount);
+		kref_init(&misc_dev->refcount);
 	} else {
-		kref_get(&sev_misc_dev->refcount);
+		kref_get(&misc_dev->refcount);
 	}
 
 	init_waitqueue_head(&psp->sev_int_queue);
-	psp->sev_misc = sev_misc_dev;
+	psp->sev_misc = misc_dev;
 	dev_info(dev, "registered SEV device\n");
 
 	return 0;
@@ -340,9 +340,9 @@ static int sev_init(struct psp_device *psp)
 
 static void sev_exit(struct kref *ref)
 {
-	struct sev_misc_dev *sev_dev = container_of(ref, struct sev_misc_dev, refcount);
+	struct sev_misc_dev *misc_dev = container_of(ref, struct sev_misc_dev, refcount);
 
-	misc_deregister(&sev_dev->misc);
+	misc_deregister(&misc_dev->misc);
 }
 
 int psp_dev_init(struct sp_device *sp)
@@ -405,7 +405,7 @@ void psp_dev_destroy(struct sp_device *sp)
 	struct psp_device *psp = sp->psp_data;
 
 	if (psp->sev_misc)
-		kref_put(&sev_misc_dev->refcount, sev_exit);
+		kref_put(&misc_dev->refcount, sev_exit);
 
 	sp_free_psp_irq(sp, psp);
 }
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 21511419bfe6..eac850a97610 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -525,7 +525,7 @@ int sev_platform_shutdown(int *error);
 /**
  * sev_platform_status - perform SEV PLATFORM_STATUS command
  *
- * @init: sev_data_status structure to be processed
+ * @status: sev_user_data_status structure to be processed
  * @error: SEV command return code
  *
  * Returns:

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
@ 2017-10-23  7:42     ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
  2017-10-29 21:16   ` [Part2 PATCH v6.1 " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  7:42 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:49PM -0500, Brijesh Singh wrote:
> The SEV_FACTORY_RESET command can be used by the platform owner to
> reset the non-volatile SEV related data. The command is defined in
> SEV spec section 5.4
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
@ 2017-10-23  7:42     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  7:42 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:49PM -0500, Brijesh Singh wrote:
> The SEV_FACTORY_RESET command can be used by the platform owner to
> reset the non-volatile SEV related data. The command is defined in
> SEV spec section 5.4
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
@ 2017-10-23  8:48   ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
  2017-10-30  3:13   ` [Part2 PATCH v6.1 15/38] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  8:48 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:50PM -0500, Brijesh Singh wrote:
> The SEV_PLATFORM_STATUS command can be used by the platform owner to
> get the current status of the platform. The command is defined in
> SEV spec section 5.5.
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-10-23  9:20     ` Borislav Petkov
  2017-10-23  9:20     ` Borislav Petkov
  2017-10-29 20:48   ` [Part2 PATCH v6.1 16/38] " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  9:20 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:48PM -0500, Brijesh Singh wrote:
> +static int __sev_platform_init(struct sev_data_init *data, int *error)
> +{
> +	int rc = 0;
> +
> +	mutex_lock(&fw_init_mutex);
> +
> +	if (!fw_init_count) {

I still don't like global semaphores. Can you get the status and check
for PSTATE.INIT state and do the init only if the platform is in
PSTATE.UNINIT?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
@ 2017-10-23  9:20     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  9:20 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:48PM -0500, Brijesh Singh wrote:
> +static int __sev_platform_init(struct sev_data_init *data, int *error)
> +{
> +	int rc = 0;
> +
> +	mutex_lock(&fw_init_mutex);
> +
> +	if (!fw_init_count) {

I still don't like global semaphores. Can you get the status and check
for PSTATE.INIT state and do the init only if the platform is in
PSTATE.UNINIT?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 16/38] " Brijesh Singh
@ 2017-10-23  9:32   ` Borislav Petkov
  2017-10-23 12:15     ` Brijesh Singh
  2017-10-23 21:55   ` [Part2 PATCH v6.1 " Brijesh Singh
  1 sibling, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23  9:32 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:51PM -0500, Brijesh Singh wrote:
> The SEV_PEK_GEN command is used to generate a new Platform Endorsement
> Key (PEK). The command is defined in SEV spec section 5.6.
> 
> 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 | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 5c921b36bc23..1d7212da25a5 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -195,6 +195,24 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
>  	return ret;
>  }
>  
> +static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
> +{
> +	int ret, err;
> +
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		return ret;
> +
> +	ret = sev_do_cmd(cmd, 0, &argp->error);

So this ret value gets potentially overwritten here. You need
to either handle the case properly when sev_do_cmd() fails and
sev_platform_shutdown() gets to issue SEV_CMD_SHUTDOWN (i.e., when it
gets overwritten), or not write into ret at all by initializing it to 0
at function entry.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23  9:32   ` Borislav Petkov
@ 2017-10-23 12:15     ` Brijesh Singh
  2017-10-23 12:32       ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 12:15 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/23/17 4:32 AM, Borislav Petkov wrote:
...
>> +static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
>> +{
>> +	int ret, err;
>> +
>> +	ret = sev_platform_init(NULL, &argp->error);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = sev_do_cmd(cmd, 0, &argp->error);
> So this ret value gets potentially overwritten here. You need
> to either handle the case properly when sev_do_cmd() fails and
> sev_platform_shutdown() gets to issue SEV_CMD_SHUTDOWN (i.e., when it
> gets overwritten), or not write into ret at all by initializing it to 0
> at function entry.
>

I am not sure if I am able to understand your feedback. The
sev_platform_shutdown() is called unconditionally.

1) if sev_do_cmd() fails and sev_platform_shutdown() was success then
'ret' will contain the  error code from sev_do_cmd().
2) if sev_do_cmd() was success but sev_platform_shutdown() fails then
'ret' will contain the error code from sev_platform_shutdown()
3) if both sev_do_cmd() and sev_platform_shutdown() fails then 'ret'
will contain error code from the sev_platform_shutdown().

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 12:15     ` Brijesh Singh
@ 2017-10-23 12:32       ` Borislav Petkov
  2017-10-23 13:32         ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23 12:32 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Mon, Oct 23, 2017 at 07:15:30AM -0500, Brijesh Singh wrote:
> I am not sure if I am able to understand your feedback. The
> sev_platform_shutdown() is called unconditionally.

How's that:

If sev_do_cmd() fails and sev_do_cmd(SEV_CMD_SHUTDOWN, ...) in
sev_platform_shutdown() fails, then the first ret from sev_do_cmd() is
gone.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
@ 2017-10-23 12:35   ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
  1 sibling, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23 12:35 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:52PM -0500, Brijesh Singh wrote:
> The SEV_PDH_GEN command is used to re-generate the Platform
> Diffie-Hellman (PDH) key. The command is defined in SEV spec section
> 5.6.
> 
> 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 | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
@ 2017-10-23 12:49     ` Borislav Petkov
  2017-10-23 22:10   ` [Part2 PATCH v6.1 " Brijesh Singh
  1 sibling, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23 12:49 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:53PM -0500, Brijesh Singh wrote:
> The SEV_PEK_CSR command can be used to generate a PEK certificate
> signing request. The command is defined in SEV spec section 5.7.
> 
> 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 | 69 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)

Improvements-by: Borislav Petkov <bp@suse.de>

> +static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_pek_csr input;
> +	struct sev_data_pek_csr *data;
> +	void *blob = NULL;
> +	int ret, err;
> +
> +	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> +		return -EFAULT;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	/* userspace wants to query CSR length */
> +	if (!input.address || !input.length)
> +		goto cmd;
> +
> +	/* allocate a physically contiguous buffer to store the CSR blob */
> +	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> +	    input.length > SEV_FW_BLOB_MAX_SIZE) {
> +		ret = -EFAULT;
> +		goto e_free;
> +	}
> +
> +	blob = kmalloc(input.length, GFP_KERNEL);
> +	if (!blob) {
> +		ret = -ENOMEM;
> +		goto e_free;
> +	}
> +
> +	data->address = __psp_pa(blob);
> +	data->len = input.length;
> +
> +cmd:
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		goto e_free_blob;
> +
> +	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);

This is the same issue: nothing is handling the case where sev_do_cmd()
here fails. If it doesn't matter, then you should simply do:

	sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);

along with explaining why we don't care about the command failing. But
simply writing into ret to overwrite it later, looks strange.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
@ 2017-10-23 12:49     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23 12:49 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 19, 2017 at 09:33:53PM -0500, Brijesh Singh wrote:
> The SEV_PEK_CSR command can be used to generate a PEK certificate
> signing request. The command is defined in SEV spec section 5.7.
> 
> 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 | 69 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)

Improvements-by: Borislav Petkov <bp@suse.de>

> +static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_pek_csr input;
> +	struct sev_data_pek_csr *data;
> +	void *blob = NULL;
> +	int ret, err;
> +
> +	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> +		return -EFAULT;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	/* userspace wants to query CSR length */
> +	if (!input.address || !input.length)
> +		goto cmd;
> +
> +	/* allocate a physically contiguous buffer to store the CSR blob */
> +	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> +	    input.length > SEV_FW_BLOB_MAX_SIZE) {
> +		ret = -EFAULT;
> +		goto e_free;
> +	}
> +
> +	blob = kmalloc(input.length, GFP_KERNEL);
> +	if (!blob) {
> +		ret = -ENOMEM;
> +		goto e_free;
> +	}
> +
> +	data->address = __psp_pa(blob);
> +	data->len = input.length;
> +
> +cmd:
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		goto e_free_blob;
> +
> +	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);

This is the same issue: nothing is handling the case where sev_do_cmd()
here fails. If it doesn't matter, then you should simply do:

	sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);

along with explaining why we don't care about the command failing. But
simply writing into ret to overwrite it later, looks strange.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 12:32       ` Borislav Petkov
@ 2017-10-23 13:32         ` Brijesh Singh
  2017-10-23 14:10           ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 13:32 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/23/17 7:32 AM, Borislav Petkov wrote:
> On Mon, Oct 23, 2017 at 07:15:30AM -0500, Brijesh Singh wrote:
>> I am not sure if I am able to understand your feedback. The
>> sev_platform_shutdown() is called unconditionally.
> How's that:
>
> If sev_do_cmd() fails and sev_do_cmd(SEV_CMD_SHUTDOWN, ...) in
> sev_platform_shutdown() fails, then the first ret from sev_do_cmd() is
> gone.

If both the command fails then we return status from the last command.
IIRC, in my previous patches I was returning status from sev_do_cmd()
instead of sev_platform_shutdown() but based on our previous
communication I thought you asked to return the status from the last
failed command. Did I miss understood ?

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 13:32         ` Brijesh Singh
@ 2017-10-23 14:10           ` Borislav Petkov
  2017-10-23 20:00             ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-23 14:10 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Mon, Oct 23, 2017 at 08:32:57AM -0500, Brijesh Singh wrote:
> If both the command fails then we return status from the last command.
> IIRC, in my previous patches I was returning status from sev_do_cmd()
> instead of sev_platform_shutdown() but based on our previous
> communication I thought you asked to return the status from the last
> failed command. Did I miss understood ?

So my problem is that it looks strange that you save an error value from
sev_do_cmd() but you don't look at it. And as I said in the other mail,
you should either ignore it and say so in a comment why it is OK to
ignore it or handle it but not overwrite it without looking at it.

Does that make more sense?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-23  9:20     ` Borislav Petkov
  (?)
@ 2017-10-23 19:57     ` Brijesh Singh
  2017-10-26 13:56       ` Borislav Petkov
  -1 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 19:57 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/23/2017 04:20 AM, Borislav Petkov wrote:
> On Thu, Oct 19, 2017 at 09:33:48PM -0500, Brijesh Singh wrote:
>> +static int __sev_platform_init(struct sev_data_init *data, int *error)
>> +{
>> +	int rc = 0;
>> +
>> +	mutex_lock(&fw_init_mutex);
>> +
>> +	if (!fw_init_count) {
> 
> I still don't like global semaphores. Can you get the status and check
> for PSTATE.INIT state and do the init only if the platform is in
> PSTATE.UNINIT?
> 


Calling PLATFORM_GET_STATUS is not required, we can manage the state 
through a simple ref count variable. Issuing PSP commands will always be 
much more expensive compare to accessing a protected global variable. I 
would prefer to avoid invoking PSP command if possible. Additionally, 
the global semaphore is still needed to serialize the 
sev_platform_init() and sev_platform_shutdown() from multiple processes. 
e.g If process "A" calls sev_platform_init() and if it gets preempted 
due to whatever reason then we don't want another process to issue the 
shutdown command while process "A" is in middle of sev_platform_init().

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 14:10           ` Borislav Petkov
@ 2017-10-23 20:00             ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 20:00 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/23/2017 09:10 AM, Borislav Petkov wrote:
> On Mon, Oct 23, 2017 at 08:32:57AM -0500, Brijesh Singh wrote:
>> If both the command fails then we return status from the last command.
>> IIRC, in my previous patches I was returning status from sev_do_cmd()
>> instead of sev_platform_shutdown() but based on our previous
>> communication I thought you asked to return the status from the last
>> failed command. Did I miss understood ?
> 
> So my problem is that it looks strange that you save an error value from
> sev_do_cmd() but you don't look at it. And as I said in the other mail,
> you should either ignore it and say so in a comment why it is OK to
> ignore it or handle it but not overwrite it without looking at it.
> 
> Does that make more sense?
> 

I see your point, if both commands failed then I am now inclined towards 
ignoring the error code from shutdown command and add some comments 
explaining why its OK. thanks

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-23  7:34     ` Borislav Petkov
  (?)
@ 2017-10-23 20:05     ` Brijesh Singh
  -1 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 20:05 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/23/2017 02:34 AM, Borislav Petkov wrote:
...

> 
> Just minor cleanups:
> 

Thanks Boris, I have applied your cleanups.

-Brijesh

> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index e9966d5fc6c4..f9a9a6e6ab99 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -31,7 +31,7 @@
>   static DEFINE_MUTEX(sev_cmd_mutex);
>   static DEFINE_MUTEX(fw_init_mutex);
>   
> -static struct sev_misc_dev *sev_misc_dev;
> +static struct sev_misc_dev *misc_dev;
>   static int fw_init_count;
>   
>   static struct psp_device *psp_alloc_struct(struct sp_device *sp)
> @@ -299,14 +299,14 @@ static int sev_ops_init(struct psp_device *psp)
>   	 * sev_do_cmd() finds the right master device to which to issue the
>   	 * command to the firmware.
>   	 */
> -	if (!sev_misc_dev) {
> +	if (!misc_dev) {
>   		struct miscdevice *misc;
>   
> -		sev_misc_dev = devm_kzalloc(dev, sizeof(*sev_misc_dev), GFP_KERNEL);
> -		if (!sev_misc_dev)
> +		misc_dev = devm_kzalloc(dev, sizeof(*misc_dev), GFP_KERNEL);
> +		if (!misc_dev)
>   			return -ENOMEM;
>   
> -		misc = &sev_misc_dev->misc;
> +		misc = &misc_dev->misc;
>   		misc->minor = MISC_DYNAMIC_MINOR;
>   		misc->name = DEVICE_NAME;
>   		misc->fops = &sev_fops;
> @@ -315,13 +315,13 @@ static int sev_ops_init(struct psp_device *psp)
>   		if (ret)
>   			return ret;
>   
> -		kref_init(&sev_misc_dev->refcount);
> +		kref_init(&misc_dev->refcount);
>   	} else {
> -		kref_get(&sev_misc_dev->refcount);
> +		kref_get(&misc_dev->refcount);
>   	}
>   
>   	init_waitqueue_head(&psp->sev_int_queue);
> -	psp->sev_misc = sev_misc_dev;
> +	psp->sev_misc = misc_dev;
>   	dev_info(dev, "registered SEV device\n");
>   
>   	return 0;
> @@ -340,9 +340,9 @@ static int sev_init(struct psp_device *psp)
>   
>   static void sev_exit(struct kref *ref)
>   {
> -	struct sev_misc_dev *sev_dev = container_of(ref, struct sev_misc_dev, refcount);
> +	struct sev_misc_dev *misc_dev = container_of(ref, struct sev_misc_dev, refcount);
>   
> -	misc_deregister(&sev_dev->misc);
> +	misc_deregister(&misc_dev->misc);
>   }
>   
>   int psp_dev_init(struct sp_device *sp)
> @@ -405,7 +405,7 @@ void psp_dev_destroy(struct sp_device *sp)
>   	struct psp_device *psp = sp->psp_data;
>   
>   	if (psp->sev_misc)
> -		kref_put(&sev_misc_dev->refcount, sev_exit);
> +		kref_put(&misc_dev->refcount, sev_exit);
>   
>   	sp_free_psp_irq(sp, psp);
>   }
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 21511419bfe6..eac850a97610 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -525,7 +525,7 @@ int sev_platform_shutdown(int *error);
>   /**
>    * sev_platform_status - perform SEV PLATFORM_STATUS command
>    *
> - * @init: sev_data_status structure to be processed
> + * @status: sev_user_data_status structure to be processed
>    * @error: SEV command return code
>    *
>    * Returns:
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 16/38] " Brijesh Singh
  2017-10-23  9:32   ` Borislav Petkov
@ 2017-10-23 21:55   ` Brijesh Singh
  2017-10-24 18:42     ` Gary R Hook
  2017-10-26 14:22     ` Borislav Petkov
  1 sibling, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 21:55 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.

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 v6:
 * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
   the error status code from sev_do_cmd() because it can give us
   much better reason for the failure.

 drivers/crypto/ccp/psp-dev.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index dd4bab143de9..18e2d8291997 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -195,6 +195,34 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
+{
+	int ret, err;
+
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		return ret;
+
+	ret = sev_do_cmd(cmd, 0, &argp->error);
+
+	if (sev_platform_shutdown(&err)) {
+		/*
+		 * If both sev_do_cmd() and sev_platform_shutdown() commands
+		 * failed then propogate the error code from the sev_do_cmd()
+		 * because it contains a useful status code for the command
+		 * failure.
+		 */
+		if (ret)
+			goto done;
+
+		argp->error = err;
+		ret = -EIO;
+	}
+
+done:
+	return ret;
+}
+
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
 	void __user *argp = (void __user *)arg;
@@ -218,6 +246,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PLATFORM_STATUS:
 		ret = sev_ioctl_do_platform_status(&input);
 		break;
+	case SEV_PEK_GEN:
+		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (37 preceding siblings ...)
  2017-10-20  2:34 ` [Part2 PATCH v6 38/38] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
@ 2017-10-23 22:07 ` Brijesh Singh
  2017-10-24 12:14 ` [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
  39 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 22:07 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.

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 v6:
 * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
   the error status code from sev_do_cmd() because it can give us
   much better reason for the failure.

 drivers/crypto/ccp/psp-dev.c | 81 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 3672435150cf..aaf1c5cf821d 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -223,6 +223,84 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_csr input;
+	struct sev_data_pek_csr *data;
+	void *blob = NULL;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* userspace wants to query CSR length */
+	if (!input.address || !input.length)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the CSR blob */
+	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
+	    input.length > SEV_FW_BLOB_MAX_SIZE) {
+		ret = -EFAULT;
+		goto e_free;
+	}
+
+	blob = kmalloc(input.length, GFP_KERNEL);
+	if (!blob) {
+		ret = -ENOMEM;
+		goto e_free;
+	}
+
+	data->address = __psp_pa(blob);
+	data->len = input.length;
+
+cmd:
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_blob;
+
+	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+	/*
+	 * If we query the CSR length, FW responded with expected data
+	 */
+	input.length = data->len;
+
+	if (sev_platform_shutdown(&err)) {
+		/*
+		 * If both sev_do_cmd() and sev_platform_shutdown() commands
+		 * failed then propogate the error code from the sev_do_cmd()
+		 * because it contains a useful status code for the command
+		 * failure.
+		 */
+		if (ret)
+			goto e_free_blob;
+
+		ret = -EIO;
+		argp->error = err;
+		goto e_free_blob;
+	}
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
+		ret = -EFAULT;
+		goto e_free_blob;
+	}
+
+	if (blob) {
+		if (copy_to_user((void __user *)input.address, blob, input.length))
+			ret = -EFAULT;
+	}
+
+e_free_blob:
+	kfree(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;
@@ -252,6 +330,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PDH_GEN:
 		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
 		break;
+	case SEV_PEK_CSR:
+		ret = sev_ioctl_do_pek_csr(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
  2017-10-23 12:49     ` Borislav Petkov
@ 2017-10-23 22:10   ` Brijesh Singh
  2017-10-24 18:42     ` Gary R Hook
  2017-10-30  3:23     ` [Part2 PATCH v6.2 " Brijesh Singh
  1 sibling, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 22:10 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.

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 v6:
 * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
   the error status code from sev_do_cmd() because it can give us
   much better reason for the failure.

 drivers/crypto/ccp/psp-dev.c | 81 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 3672435150cf..aaf1c5cf821d 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -223,6 +223,84 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_csr input;
+	struct sev_data_pek_csr *data;
+	void *blob = NULL;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* userspace wants to query CSR length */
+	if (!input.address || !input.length)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the CSR blob */
+	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
+	    input.length > SEV_FW_BLOB_MAX_SIZE) {
+		ret = -EFAULT;
+		goto e_free;
+	}
+
+	blob = kmalloc(input.length, GFP_KERNEL);
+	if (!blob) {
+		ret = -ENOMEM;
+		goto e_free;
+	}
+
+	data->address = __psp_pa(blob);
+	data->len = input.length;
+
+cmd:
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_blob;
+
+	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+	/*
+	 * If we query the CSR length, FW responded with expected data
+	 */
+	input.length = data->len;
+
+	if (sev_platform_shutdown(&err)) {
+		/*
+		 * If both sev_do_cmd() and sev_platform_shutdown() commands
+		 * failed then propogate the error code from the sev_do_cmd()
+		 * because it contains a useful status code for the command
+		 * failure.
+		 */
+		if (ret)
+			goto e_free_blob;
+
+		ret = -EIO;
+		argp->error = err;
+		goto e_free_blob;
+	}
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
+		ret = -EFAULT;
+		goto e_free_blob;
+	}
+
+	if (blob) {
+		if (copy_to_user((void __user *)input.address, blob, input.length))
+			ret = -EFAULT;
+	}
+
+e_free_blob:
+	kfree(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;
@@ -252,6 +330,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PDH_GEN:
 		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
 		break;
+	case SEV_PEK_CSR:
+		ret = sev_ioctl_do_pek_csr(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
@ 2017-10-23 22:14   ` Brijesh Singh
  2017-10-24 18:42     ` Gary R Hook
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 22:14 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK
certificate. The command is defined in SEV spec section 5.8.

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 v6:
 * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
   the error status code from sev_do_cmd() because it can give us
   much better reason for the failure.

 drivers/crypto/ccp/psp-dev.c | 92 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/psp-sev.h      |  4 ++
 2 files changed, 96 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index aaf1c5cf821d..108fc06bcdb3 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -301,6 +301,95 @@ static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+void *psp_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 (!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);
+}
+EXPORT_SYMBOL_GPL(psp_copy_user_blob);
+
+static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_cert_import input;
+	struct sev_data_pek_cert_import *data;
+	void *pek_blob, *oca_blob;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* copy PEK certificate blobs from userspace */
+	pek_blob = psp_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 = psp_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_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_oca;
+
+	ret = sev_do_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+
+	if (sev_platform_shutdown(&err)) {
+		/*
+		 * If both sev_do_cmd() and sev_platform_shutdown() commands
+		 * failed then propogate the error code from the sev_do_cmd()
+		 * because it contains a useful status code for the command
+		 * failure.
+		 */
+		if (ret)
+			goto e_free_oca;
+
+		ret = -EIO;
+		argp->error = err;
+	}
+
+e_free_oca:
+	kfree(oca_blob);
+e_free_pek:
+	kfree(pek_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;
@@ -333,6 +422,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PEK_CSR:
 		ret = sev_ioctl_do_pek_csr(&input);
 		break;
+	case SEV_PEK_CERT_IMPORT:
+		ret = sev_ioctl_do_pek_cert_import(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index eac850a97610..d535153ca82d 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -620,6 +620,8 @@ int sev_guest_df_flush(int *error);
  */
 int sev_guest_decommission(struct sev_data_decommission *data, int *error);
 
+void *psp_copy_user_blob(u64 __user uaddr, u32 len);
+
 #else	/* !CONFIG_CRYPTO_DEV_SP_PSP */
 
 static inline int
@@ -648,6 +650,8 @@ sev_issue_cmd_external_user(struct file *filep,
 	return -ENODEV;
 }
 
+static inline void *psp_copy_user_blob(u64 __user uaddr, u32 len) { return ERR_PTR(-EINVAL); }
+
 #endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
 
 #endif	/* __PSP_SEV_H__ */
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
@ 2017-10-23 22:19   ` Brijesh Singh
  2017-10-24 18:43     ` Gary R Hook
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 22:19 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its
certificate chain. The command is defined in SEV spec section 5.10.

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 v6:
 * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
   the error status code from sev_do_cmd() because it can give us
   much better reason for the failure.

 drivers/crypto/ccp/psp-dev.c | 110 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 108fc06bcdb3..b9f594cb10c1 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -390,6 +390,113 @@ static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pdh_cert_export(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pdh_cert_export input;
+	void *pdh_blob = NULL, *cert_blob = NULL;
+	struct sev_data_pdh_cert_export *data;
+	int ret, err;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* Userspace wants to query the certificate length */
+	if (!input.pdh_cert_address || !input.pdh_cert_len ||
+	    !input.cert_chain_address || !input.cert_chain_address)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the PDH blob */
+	if (!access_ok(VERIFY_WRITE, input.pdh_cert_address, input.pdh_cert_len) ||
+	    (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE)) {
+		ret = -EFAULT;
+		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;
+
+	/* allocate a physically contiguous buffer to store the cert chain blob */
+	if (!access_ok(VERIFY_WRITE, input.cert_chain_address, input.cert_chain_len) ||
+	    (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE)) {
+		ret = -EFAULT;
+		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;
+
+cmd:
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		goto e_free_cert;
+
+	ret = sev_do_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+
+	/*
+	 * If we query the length, FW responded with expected data
+	 */
+	input.cert_chain_len = data->cert_chain_len;
+	input.pdh_cert_len = data->pdh_cert_len;
+
+	if (sev_platform_shutdown(&err)) {
+		/*
+		 * If both sev_do_cmd() and sev_platform_shutdown() commands
+		 * failed then propogate the error code from the sev_do_cmd()
+		 * because it contains a useful status code for the command
+		 * failure.
+		 */
+		if (ret)
+			goto e_free_cert;
+
+		ret = -EIO;
+		argp->error = err;
+		goto e_free_cert;
+	}
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
+		ret = -EFAULT;
+		goto e_free_cert;
+	}
+
+	if (pdh_blob) {
+		if (copy_to_user((void __user *)input.pdh_cert_address,
+				 pdh_blob, input.pdh_cert_len)) {
+			ret = -EFAULT;
+			goto e_free_cert;
+		}
+	}
+
+	if (cert_blob) {
+		if (copy_to_user((void __user *)input.cert_chain_address,
+				 cert_blob, input.cert_chain_len))
+			ret = -EFAULT;
+	}
+
+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;
@@ -425,6 +532,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PEK_CERT_IMPORT:
 		ret = sev_ioctl_do_pek_cert_import(&input);
 		break;
+	case SEV_PDH_CERT_EXPORT:
+		ret = sev_ioctl_do_pdh_cert_export(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
  2017-10-20 13:18   ` Jonathan Corbet
@ 2017-10-23 22:40     ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-23 22:40 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: brijesh.singh, kvm, bp, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Tom Lendacky, x86, linux-kernel



On 10/20/2017 08:18 AM, Jonathan Corbet wrote:
> On Thu, 19 Oct 2017 21:33:36 -0500
> Brijesh Singh <brijesh.singh@amd.com> wrote:
> 
>> Create a Documentation entry to describe the AMD Secure Encrypted
>> Virtualization (SEV) feature.
> 
> A couple of quick notes...
> 
>   - This is describing an x86 subarchitecture feature, so it seems to me
>     that Documentation/x86 would be a more logical place for it.  Yes, KVM
>     can use this feature, but it's not a KVM feature and there might be
>     something else that takes advantage of it too.
> 

In part1 of SEV patches, we do expand the 
Documentation/x86/amd-memory-eencryption.txt to explain the SEV 
architecture feature. In this patch, we focus on documenting the SEV 
specific changes from the KVM point of view and how it integrate with KVM.


>   - Any chance of getting it formatted as RST?  It's almost there already.
> 

Sure, next rev I will convert it to RST format.


> Beyond that, the document obviously falls far short of what one would
> have to know to use SEV; probably filling all that in would make it long
> indeed.
> 

In later part of patches (Patch 24/38 [1]), I expand this doc to provide 
high level overview of various SEV commands to support common lifecycle 
events of SEV guests, such as launching, running, snapshotting, 
migrating etc.

[1] https://patchwork.kernel.org/patch/10018671/

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD)
  2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
                   ` (38 preceding siblings ...)
  2017-10-23 22:07 ` [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command Brijesh Singh
@ 2017-10-24 12:14 ` Brijesh Singh
  2017-11-02 20:18   ` Brijesh Singh
  39 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-24 12:14 UTC (permalink / raw)
  To: Brijesh Singh, Herbert Xu, Paolo Bonzini
  Cc: brijesh.singh, kvm list, linux-crypto, Borislav Petkov, Lendacky,
	Thomas, Gary Hook

Hi Herbert and Paolo,


On 10/19/17 9:33 PM, Brijesh Singh wrote:
> This part of Secure Encryted Virtualization (SEV) patch series focuses on KVM
> changes required to create and manage SEV guests.
>
> SEV is an extension to the AMD-V architecture which supports running encrypted
> virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have their
> pages (code and data) secured such that only the guest itself has access to
> unencrypted version. Each encrypted VM is associated with a unique encryption key;
> if its data is accessed to a different entity using a different key the encrypted
> guest's data will be incorrectly decrypted, leading to unintelligible data.
> This security model ensures that hypervisor will no longer able to inspect or
> alter any guest code or data.
>
> The key management of this feature is handled by a separate processor known as
> the AMD Secure Processor (AMD-SP) which is present on AMD SOCs. The SEV Key
> Management Specification (see below) provides a set of commands which can be
> used by hypervisor to load virtual machine keys through the AMD-SP driver.

Since the PSP patches touches both the CCP and KVM driver, hence I was
wondering if you guys have any thought on how PSP patches will be
merged? I am talking about Patch 9 to 20 from this series. I have
ensured that patches apply cleanly on both kvm/master and
cryptodev-2.6/master. We can do this in one of two ways:

- Paolo can merge the PSP support through the KVM branch

or

- Herbert can create a topic branch with PSP changes and Paolo can use
that topic branch.

Any visibility will help my next submission. thank you.

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
  2017-10-20  2:33 ` [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
@ 2017-10-24 18:40   ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:40 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Borislav Petkov, Tom Lendacky, Herbert Xu, David S. Miller,
	linux-crypto

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> From: Borislav Petkov <bp@suse.de>
> 
> 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>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> 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

Reviewed-by: Gary R Hook <gary.hook@amd.com>

> ---
>   drivers/crypto/ccp/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> index 6d626606b9c5..9c84f9838931 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] 120+ messages in thread

* Re: [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id
  2017-10-20  2:33 ` [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
@ 2017-10-24 18:40   ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:40 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> Add a include file which defines the ioctl and command id used for
> issuing SEV platform management specific commands.
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> Reviewed-by: Borislav Petkov <bp@suse.de>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
>   include/uapi/linux/psp-sev.h | 113 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 113 insertions(+)
>   create mode 100644 include/uapi/linux/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..1dd98ba4ff22
> --- /dev/null
> +++ b/include/uapi/linux/psp-sev.h
> @@ -0,0 +1,113 @@
> +/*
> + * Userspace interface for AMD Secure Encrypted Virtualization (SEV)
> + * platform management commands.
> + *
> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * SEV spec 0.14 is available at:
> + * http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
> + *
> + * 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_FACTORY_RESET = 0,
> +	SEV_PLATFORM_STATUS,
> +	SEV_PEK_GEN,
> +	SEV_PEK_CSR,
> +	SEV_PDH_GEN,
> +	SEV_PDH_CERT_EXPORT,
> +	SEV_PEK_CERT_IMPORT,
> +
> +	SEV_MAX,
> +};
> +
> +/**
> + * struct sev_user_data_status - PLATFORM_STATUS command parameters
> + *
> + * @major: major API version
> + * @minor: minor API version
> + * @state: platform state
> + * @flags: 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 */
> +	__u32 flags;				/* Out */
> +	__u8 build;				/* Out */
> +	__u32 guest_count;			/* Out */
> +} __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 */
> +} __packed;
> +
> +/**
> + * 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 */
> +} __packed;
> +
> +/**
> + * 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 */
> +} __packed;
> +
> +/**
> + * 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 */
> +} __packed;
> +
> +#define SEV_IOC_TYPE		'S'
> +#define SEV_ISSUE_CMD	_IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
> +
> +#endif /* __PSP_USER_SEV_H */
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management command id
  2017-10-20  2:33 ` [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management " Brijesh Singh
@ 2017-10-24 18:40   ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:40 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> Define Secure Encrypted Virtualization (SEV) key management command id
> and structure. The command definition is available in SEV KM [1] spec
> 0.14.
> 
> [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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> Reviewed-by: Borislav Petkov <bp@suse.de>

Acked-by: Gary R Hook <gary.hook@amd.com>


> ---
>   include/linux/psp-sev.h | 494 ++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 494 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..15bda519538e
> --- /dev/null
> +++ b/include/linux/psp-sev.h
> @@ -0,0 +1,494 @@
> +/*
> + * AMD Secure Encrypted Virtualization (SEV) driver interface
> + *
> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
> + *
> + * Author: Brijesh Singh <brijesh.singh@amd.com>
> + *
> + * SEV spec 0.14 is available at:
> + * http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
> + *
> + * 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__
> +
> +#include <uapi/linux/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 sev_data_init {
> +	u32 flags;			/* In */
> +	u32 reserved;			/* In */
> +	u64 tmr_address;		/* In */
> +	u32 tmr_len;			/* In */
> +} __packed;
> +
> +/**
> + * struct sev_data_pek_csr - PEK_CSR command parameters
> + *
> + * @address: PEK certificate chain
> + * @len: len of certificate
> + */
> +struct sev_data_pek_csr {
> +	u64 address;				/* In */
> +	u32 len;				/* In/Out */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * struct sev_data_decommission - DECOMMISSION command parameters
> + *
> + * @handle: handle of the VM to decommission
> + */
> +struct sev_data_decommission {
> +	u32 handle;				/* In */
> +} __packed;
> +
> +/**
> + * struct sev_data_activate - ACTIVATE command parameters
> + *
> + * @handle: handle of the VM to activate
> + * @asid: asid assigned to the VM
> + */
> +struct sev_data_activate {
> +	u32 handle;				/* In */
> +	u32 asid;				/* In */
> +} __packed;
> +
> +/**
> + * struct sev_data_deactivate - DEACTIVATE command parameters
> + *
> + * @handle: handle of the VM to deactivate
> + */
> +struct sev_data_deactivate {
> +	u32 handle;				/* In */
> +} __packed;
> +
> +/**
> + * 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 sev_data_guest_status {
> +	u32 handle;				/* In */
> +	u32 policy;				/* Out */
> +	u32 asid;				/* Out */
> +	u8 state;				/* Out */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 sev_data_launch_update_data {
> +	u32 handle;				/* In */
> +	u32 reserved;
> +	u64 address;				/* In */
> +	u32 len;				/* In */
> +} __packed;
> +
> +/**
> + * 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 sev_data_launch_update_vmsa {
> +	u32 handle;				/* In */
> +	u32 reserved;
> +	u64 address;				/* In */
> +	u32 len;				/* In */
> +} __packed;
> +
> +/**
> + * 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 sev_data_launch_measure {
> +	u32 handle;				/* In */
> +	u32 reserved;
> +	u64 address;				/* In */
> +	u32 len;				/* In/Out */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * struct sev_data_launch_finish - LAUNCH_FINISH command parameters
> + *
> + * @handle: handle of the VM to process
> + */
> +struct sev_data_launch_finish {
> +	u32 handle;				/* In */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * struct sev_data_send_finish - SEND_FINISH command parameters
> + *
> + * @handle: handle of the VM to process
> + */
> +struct sev_data_send_finish {
> +	u32 handle;				/* In */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * 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 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 */
> +} __packed;
> +
> +/**
> + * struct sev_data_receive_finish - RECEIVE_FINISH command parameters
> + *
> + * @handle: handle of the VM to finish
> + */
> +struct sev_data_receive_finish {
> +	u32 handle;				/* In */
> +} __packed;
> +
> +/**
> + * 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 sev_data_dbg {
> +	u32 handle;				/* In */
> +	u32 reserved;
> +	u64 src_addr;				/* In */
> +	u64 dst_addr;				/* In */
> +	u32 len;				/* In */
> +} __packed;
> +
> +#endif	/* __PSP_SEV_H__ */
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support
  2017-10-20  2:33 ` [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-10-24 18:40   ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:40 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> The Platform Security Processor (PSP) is part of the AMD Secure
> Processor (AMD-SP) functionality. 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 third-party trusted applications.
> 
> Note that the key management functionality provided by the SEV firmware
> can be used outside of the kvm-amd driver hence it doesn't need to
> depend 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> Reviewed-by: Borislav Petkov <bp@suse.de>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
>   drivers/crypto/ccp/Kconfig   |  11 +++++
>   drivers/crypto/ccp/Makefile  |   1 +
>   drivers/crypto/ccp/psp-dev.c | 105 +++++++++++++++++++++++++++++++++++++++++++
>   drivers/crypto/ccp/psp-dev.h |  59 ++++++++++++++++++++++++
>   drivers/crypto/ccp/sp-dev.c  |  26 +++++++++++
>   drivers/crypto/ccp/sp-dev.h  |  24 +++++++++-
>   drivers/crypto/ccp/sp-pci.c  |  52 +++++++++++++++++++++
>   7 files changed, 277 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 9c84f9838931..b9dfae47aefd 100644
> --- a/drivers/crypto/ccp/Kconfig
> +++ b/drivers/crypto/ccp/Kconfig
> @@ -33,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 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 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..b5789f878560
> --- /dev/null
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -0,0 +1,105 @@
> +/*
> + * 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"
> +
> +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..55b7808367c3
> --- /dev/null
> +++ b/drivers/crypto/ccp/psp-dev.h
> @@ -0,0 +1,59 @@
> +/*
> + * 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;
> +};
> +
> +#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..909cf3e436b4 100644
> --- a/drivers/crypto/ccp/sp-dev.h
> +++ b/drivers/crypto/ccp/sp-dev.h
> @@ -42,12 +42,17 @@ struct ccp_vdata {
>   	const unsigned int offset;
>   	const unsigned int rsamax;
>   };
> +
> +struct psp_vdata {
> +	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 +73,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 +112,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 +140,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..f5f43c50698a 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) {
> @@ -225,6 +268,12 @@ static int sp_pci_resume(struct pci_dev *pdev)
>   }
>   #endif
>   
> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
> +static const struct psp_vdata psp_entry = {
> +	.offset = 0x10500,
> +};
> +#endif
> +
>   static const struct sp_dev_vdata dev_vdata[] = {
>   	{
>   		.bar = 2,
> @@ -237,6 +286,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,
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
  2017-10-23  8:48   ` Borislav Petkov
@ 2017-10-24 18:41   ` Gary R Hook
  2017-10-30  3:13   ` [Part2 PATCH v6.1 15/38] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:41 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> The SEV_PLATFORM_STATUS command can be used by the platform owner to
> get the current status of the platform. The command is defined in
> SEV spec section 5.5.
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
>   drivers/crypto/ccp/psp-dev.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 99f3761206da..5c921b36bc23 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -174,6 +174,27 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
>   	return ret;
>   }
>   
> +static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_status *data;
> +	int ret;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
> +	if (ret)
> +		goto e_free;
> +
> +	if (copy_to_user((void __user *)argp->data, data, sizeof(*data)))
> +		ret = -EFAULT;
> +
> +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;
> @@ -194,6 +215,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_FACTORY_RESET:
>   		ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
>   		break;
> +	case SEV_PLATFORM_STATUS:
> +		ret = sev_ioctl_do_platform_status(&input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
  2017-10-23 12:35   ` Borislav Petkov
@ 2017-10-24 18:41   ` Gary R Hook
  1 sibling, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:41 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> The SEV_PDH_GEN command is used to re-generate the Platform
> Diffie-Hellman (PDH) key. The command is defined in SEV spec section
> 5.6.
> 
> 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>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
>   drivers/crypto/ccp/psp-dev.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 1d7212da25a5..d9771d104eea 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -239,6 +239,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_PEK_GEN:
>   		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
>   		break;
> +	case SEV_PDH_GEN:
> +		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
  2017-10-23  7:42     ` Borislav Petkov
@ 2017-10-24 18:41   ` Gary R Hook
  2017-10-29 21:16   ` [Part2 PATCH v6.1 " Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:41 UTC (permalink / raw)
  To: Brijesh Singh, kvm
  Cc: bp, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto,
	linux-kernel

On 10/19/2017 09:33 PM, Brijesh Singh wrote:
> The SEV_FACTORY_RESET command can be used by the platform owner to
> reset the non-volatile SEV related data. The command is defined in
> SEV spec section 5.4
> 
> 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
>   drivers/crypto/ccp/psp-dev.c | 28 +++++++++++++++++++++++++++-
>   1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index e9966d5fc6c4..99f3761206da 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -176,7 +176,33 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
>   
>   static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   {
> -	return -ENOTTY;
> +	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_MAX)
> +		return -EINVAL;
> +
> +	switch (input.cmd) {
> +
> +	case SEV_FACTORY_RESET:
> +		ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
> +		ret = -EFAULT;
> +out:
> +	return ret;
>   }
>   
>   static const struct file_operations sev_fops = {
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 21:55   ` [Part2 PATCH v6.1 " Brijesh Singh
@ 2017-10-24 18:42     ` Gary R Hook
  2017-10-26 14:22     ` Borislav Petkov
  1 sibling, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:42 UTC (permalink / raw)
  To: Brijesh Singh, Borislav Petkov
  Cc: Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On 10/23/2017 04:55 PM, Brijesh Singh wrote:
> The SEV_PEK_GEN command is used to generate a new Platform Endorsement
> Key (PEK). The command is defined in SEV spec section 5.6.
> 
> 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>

Acked-by: Gary R Hook <gary.hook@amd.com>

> ---
> 
> Changes since v6:
>   * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
>     the error status code from sev_do_cmd() because it can give us
>     much better reason for the failure.
> 
>   drivers/crypto/ccp/psp-dev.c | 31 +++++++++++++++++++++++++++++++
>   1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index dd4bab143de9..18e2d8291997 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -195,6 +195,34 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
>   	return ret;
>   }
>   
> +static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
> +{
> +	int ret, err;
> +
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		return ret;
> +
> +	ret = sev_do_cmd(cmd, 0, &argp->error);
> +
> +	if (sev_platform_shutdown(&err)) {
> +		/*
> +		 * If both sev_do_cmd() and sev_platform_shutdown() commands
> +		 * failed then propogate the error code from the sev_do_cmd()
> +		 * because it contains a useful status code for the command
> +		 * failure.
> +		 */
> +		if (ret)
> +			goto done;
> +
> +		argp->error = err;
> +		ret = -EIO;
> +	}
> +
> +done:
> +	return ret;
> +}
> +
>   static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   {
>   	void __user *argp = (void __user *)arg;
> @@ -218,6 +246,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_PLATFORM_STATUS:
>   		ret = sev_ioctl_do_platform_status(&input);
>   		break;
> +	case SEV_PEK_GEN:
> +		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-23 22:10   ` [Part2 PATCH v6.1 " Brijesh Singh
@ 2017-10-24 18:42     ` Gary R Hook
  2017-10-30  3:23     ` [Part2 PATCH v6.2 " Brijesh Singh
  1 sibling, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:42 UTC (permalink / raw)
  To: Brijesh Singh, Borislav Petkov
  Cc: Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On 10/23/2017 05:10 PM, Brijesh Singh wrote:
> The SEV_PEK_CSR command can be used to generate a PEK certificate
> signing request. The command is defined in SEV spec section 5.7.
> 
> 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>
> ---


Acked-by: Gary R Hook <gary.hook@amd.com>



> 
> Changes since v6:
>   * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
>     the error status code from sev_do_cmd() because it can give us
>     much better reason for the failure.
> 
>   drivers/crypto/ccp/psp-dev.c | 81 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 81 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 3672435150cf..aaf1c5cf821d 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -223,6 +223,84 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
>   	return ret;
>   }
>   
> +static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_pek_csr input;
> +	struct sev_data_pek_csr *data;
> +	void *blob = NULL;
> +	int ret, err;
> +
> +	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> +		return -EFAULT;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	/* userspace wants to query CSR length */
> +	if (!input.address || !input.length)
> +		goto cmd;
> +
> +	/* allocate a physically contiguous buffer to store the CSR blob */
> +	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> +	    input.length > SEV_FW_BLOB_MAX_SIZE) {
> +		ret = -EFAULT;
> +		goto e_free;
> +	}
> +
> +	blob = kmalloc(input.length, GFP_KERNEL);
> +	if (!blob) {
> +		ret = -ENOMEM;
> +		goto e_free;
> +	}
> +
> +	data->address = __psp_pa(blob);
> +	data->len = input.length;
> +
> +cmd:
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		goto e_free_blob;
> +
> +	ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
> +
> +	/*
> +	 * If we query the CSR length, FW responded with expected data
> +	 */
> +	input.length = data->len;
> +
> +	if (sev_platform_shutdown(&err)) {
> +		/*
> +		 * If both sev_do_cmd() and sev_platform_shutdown() commands
> +		 * failed then propogate the error code from the sev_do_cmd()
> +		 * because it contains a useful status code for the command
> +		 * failure.
> +		 */
> +		if (ret)
> +			goto e_free_blob;
> +
> +		ret = -EIO;
> +		argp->error = err;
> +		goto e_free_blob;
> +	}
> +
> +	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
> +		ret = -EFAULT;
> +		goto e_free_blob;
> +	}
> +
> +	if (blob) {
> +		if (copy_to_user((void __user *)input.address, blob, input.length))
> +			ret = -EFAULT;
> +	}
> +
> +e_free_blob:
> +	kfree(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;
> @@ -252,6 +330,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_PDH_GEN:
>   		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
>   		break;
> +	case SEV_PEK_CSR:
> +		ret = sev_ioctl_do_pek_csr(&input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
  2017-10-23 22:14   ` [Part2 PATCH v6.1 " Brijesh Singh
@ 2017-10-24 18:42     ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:42 UTC (permalink / raw)
  To: Brijesh Singh, Borislav Petkov
  Cc: Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On 10/23/2017 05:14 PM, Brijesh Singh wrote:
> The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK
> certificate. The command is defined in SEV spec section 5.8.
> 
> 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>


Acked-by: Gary R Hook <gary.hook@amd.com>



> ---
> 
> Changes since v6:
>   * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
>     the error status code from sev_do_cmd() because it can give us
>     much better reason for the failure.
> 
>   drivers/crypto/ccp/psp-dev.c | 92 ++++++++++++++++++++++++++++++++++++++++++++
>   include/linux/psp-sev.h      |  4 ++
>   2 files changed, 96 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index aaf1c5cf821d..108fc06bcdb3 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -301,6 +301,95 @@ static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
>   	return ret;
>   }
>   
> +void *psp_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 (!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);
> +}
> +EXPORT_SYMBOL_GPL(psp_copy_user_blob);
> +
> +static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_pek_cert_import input;
> +	struct sev_data_pek_cert_import *data;
> +	void *pek_blob, *oca_blob;
> +	int ret, err;
> +
> +	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> +		return -EFAULT;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	/* copy PEK certificate blobs from userspace */
> +	pek_blob = psp_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 = psp_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_init(NULL, &argp->error);
> +	if (ret)
> +		goto e_free_oca;
> +
> +	ret = sev_do_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
> +
> +	if (sev_platform_shutdown(&err)) {
> +		/*
> +		 * If both sev_do_cmd() and sev_platform_shutdown() commands
> +		 * failed then propogate the error code from the sev_do_cmd()
> +		 * because it contains a useful status code for the command
> +		 * failure.
> +		 */
> +		if (ret)
> +			goto e_free_oca;
> +
> +		ret = -EIO;
> +		argp->error = err;
> +	}
> +
> +e_free_oca:
> +	kfree(oca_blob);
> +e_free_pek:
> +	kfree(pek_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;
> @@ -333,6 +422,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_PEK_CSR:
>   		ret = sev_ioctl_do_pek_csr(&input);
>   		break;
> +	case SEV_PEK_CERT_IMPORT:
> +		ret = sev_ioctl_do_pek_cert_import(&input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index eac850a97610..d535153ca82d 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -620,6 +620,8 @@ int sev_guest_df_flush(int *error);
>    */
>   int sev_guest_decommission(struct sev_data_decommission *data, int *error);
>   
> +void *psp_copy_user_blob(u64 __user uaddr, u32 len);
> +
>   #else	/* !CONFIG_CRYPTO_DEV_SP_PSP */
>   
>   static inline int
> @@ -648,6 +650,8 @@ sev_issue_cmd_external_user(struct file *filep,
>   	return -ENODEV;
>   }
>   
> +static inline void *psp_copy_user_blob(u64 __user uaddr, u32 len) { return ERR_PTR(-EINVAL); }
> +
>   #endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
>   
>   #endif	/* __PSP_SEV_H__ */
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
  2017-10-23 22:19   ` [Part2 PATCH v6.1 " Brijesh Singh
@ 2017-10-24 18:43     ` Gary R Hook
  0 siblings, 0 replies; 120+ messages in thread
From: Gary R Hook @ 2017-10-24 18:43 UTC (permalink / raw)
  To: Brijesh Singh, Borislav Petkov
  Cc: Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On 10/23/2017 05:19 PM, Brijesh Singh wrote:
> The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its
> certificate chain. The command is defined in SEV spec section 5.10.
> 
> 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>


Acked-by: Gary R Hook <gary.hook@amd.com>



> ---
> 
> Changes since v6:
>   * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
>     the error status code from sev_do_cmd() because it can give us
>     much better reason for the failure.
> 
>   drivers/crypto/ccp/psp-dev.c | 110 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 110 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 108fc06bcdb3..b9f594cb10c1 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -390,6 +390,113 @@ static int sev_ioctl_do_pek_cert_import(struct sev_issue_cmd *argp)
>   	return ret;
>   }
>   
> +static int sev_ioctl_do_pdh_cert_export(struct sev_issue_cmd *argp)
> +{
> +	struct sev_user_data_pdh_cert_export input;
> +	void *pdh_blob = NULL, *cert_blob = NULL;
> +	struct sev_data_pdh_cert_export *data;
> +	int ret, err;
> +
> +	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> +		return -EFAULT;
> +
> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	/* Userspace wants to query the certificate length */
> +	if (!input.pdh_cert_address || !input.pdh_cert_len ||
> +	    !input.cert_chain_address || !input.cert_chain_address)
> +		goto cmd;
> +
> +	/* allocate a physically contiguous buffer to store the PDH blob */
> +	if (!access_ok(VERIFY_WRITE, input.pdh_cert_address, input.pdh_cert_len) ||
> +	    (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE)) {
> +		ret = -EFAULT;
> +		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;
> +
> +	/* allocate a physically contiguous buffer to store the cert chain blob */
> +	if (!access_ok(VERIFY_WRITE, input.cert_chain_address, input.cert_chain_len) ||
> +	    (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE)) {
> +		ret = -EFAULT;
> +		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;
> +
> +cmd:
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		goto e_free_cert;
> +
> +	ret = sev_do_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
> +
> +	/*
> +	 * If we query the length, FW responded with expected data
> +	 */
> +	input.cert_chain_len = data->cert_chain_len;
> +	input.pdh_cert_len = data->pdh_cert_len;
> +
> +	if (sev_platform_shutdown(&err)) {
> +		/*
> +		 * If both sev_do_cmd() and sev_platform_shutdown() commands
> +		 * failed then propogate the error code from the sev_do_cmd()
> +		 * because it contains a useful status code for the command
> +		 * failure.
> +		 */
> +		if (ret)
> +			goto e_free_cert;
> +
> +		ret = -EIO;
> +		argp->error = err;
> +		goto e_free_cert;
> +	}
> +
> +	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
> +		ret = -EFAULT;
> +		goto e_free_cert;
> +	}
> +
> +	if (pdh_blob) {
> +		if (copy_to_user((void __user *)input.pdh_cert_address,
> +				 pdh_blob, input.pdh_cert_len)) {
> +			ret = -EFAULT;
> +			goto e_free_cert;
> +		}
> +	}
> +
> +	if (cert_blob) {
> +		if (copy_to_user((void __user *)input.cert_chain_address,
> +				 cert_blob, input.cert_chain_len))
> +			ret = -EFAULT;
> +	}
> +
> +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;
> @@ -425,6 +532,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>   	case SEV_PEK_CERT_IMPORT:
>   		ret = sev_ioctl_do_pek_cert_import(&input);
>   		break;
> +	case SEV_PDH_CERT_EXPORT:
> +		ret = sev_ioctl_do_pdh_cert_export(&input);
> +		break;
>   	default:
>   		ret = -EINVAL;
>   		goto out;
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-23 19:57     ` Brijesh Singh
@ 2017-10-26 13:56       ` Borislav Petkov
  2017-10-26 16:56         ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-26 13:56 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Mon, Oct 23, 2017 at 02:57:04PM -0500, Brijesh Singh wrote:
> Calling PLATFORM_GET_STATUS is not required, we can manage the state through
> a simple ref count variable. Issuing PSP commands will always be much more
> expensive compare to accessing a protected global variable.

What does "protected" mean here?

In any case, that variable can be a simple bool as you use it as such.

> I would prefer to avoid invoking PSP command if possible.
> Additionally, the global semaphore is still needed to serialize
> the sev_platform_init() and sev_platform_shutdown() from multiple
> processes. e.g If process "A" calls sev_platform_init() and if it gets
> preempted due to whatever reason then we don't want another process
> to issue the shutdown command while process "A" is in middle of
> sev_platform_init().

How? You're holding fw_init_mutex.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-23 21:55   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-24 18:42     ` Gary R Hook
@ 2017-10-26 14:22     ` Borislav Petkov
  1 sibling, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-26 14:22 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On Mon, Oct 23, 2017 at 04:55:19PM -0500, Brijesh Singh wrote:
> The SEV_PEK_GEN command is used to generate a new Platform Endorsement
> Key (PEK). The command is defined in SEV spec section 5.6.
> 
> 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 v6:
>  * when sev_do_cmd() and sev_platform_shutdown() fails then propogate
>    the error status code from sev_do_cmd() because it can give us
>    much better reason for the failure.
> 
>  drivers/crypto/ccp/psp-dev.c | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 13:56       ` Borislav Petkov
@ 2017-10-26 16:56         ` Brijesh Singh
  2017-10-26 17:44             ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-26 16:56 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/26/2017 08:56 AM, Borislav Petkov wrote:
> On Mon, Oct 23, 2017 at 02:57:04PM -0500, Brijesh Singh wrote:
>> Calling PLATFORM_GET_STATUS is not required, we can manage the state through
>> a simple ref count variable. Issuing PSP commands will always be much more
>> expensive compare to accessing a protected global variable.
> 
> What does "protected" mean here?
> 

Access global variable after acquiring the semaphore.


> In any case, that variable can be a simple bool as you use it as such.
> 

I am not using the variable (fw_init_count) as boolean. The variable 
gets incremented in sev_platform_init() and decremented in 
sev_platform_shutdown(). In very first call to sev_platform_init (i.e 
when variable is zero) we issue  PLATFORM_INIT command, similarly 
PLATFORM_SHUTDOWN is issued on the last (i.e when variable value is 
reached to zero). The variable is used as ref counter.


>> I would prefer to avoid invoking PSP command if possible.
>> Additionally, the global semaphore is still needed to serialize
>> the sev_platform_init() and sev_platform_shutdown() from multiple
>> processes. e.g If process "A" calls sev_platform_init() and if it gets
>> preempted due to whatever reason then we don't want another process
>> to issue the shutdown command while process "A" is in middle of
>> sev_platform_init().
> 
> How? You're holding fw_init_mutex.
> 

In your previous reply you comments on global semaphore (fw_init_mutex) 
and in response I tried to highlight why we need the global semaphore. 
Did I misunderstood your comment ?

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 16:56         ` Brijesh Singh
@ 2017-10-26 17:44             ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-26 17:44 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 26, 2017 at 11:56:57AM -0500, Brijesh Singh wrote:
> The variable is used as ref counter.

... and it can't be converted to a boolean because...?

> In your previous reply you comments on global semaphore (fw_init_mutex) and
> in response I tried to highlight why we need the global semaphore. Did I
> misunderstood your comment ?

Yes, what happens if you get preempted while holding the mutex? Will the other
process be able to do anything?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
@ 2017-10-26 17:44             ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-26 17:44 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 26, 2017 at 11:56:57AM -0500, Brijesh Singh wrote:
> The variable is used as ref counter.

... and it can't be converted to a boolean because...?

> In your previous reply you comments on global semaphore (fw_init_mutex) and
> in response I tried to highlight why we need the global semaphore. Did I
> misunderstood your comment ?

Yes, what happens if you get preempted while holding the mutex? Will the other
process be able to do anything?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 17:44             ` Borislav Petkov
  (?)
@ 2017-10-26 19:26             ` Brijesh Singh
  2017-10-26 20:13               ` Borislav Petkov
  -1 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-26 19:26 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/26/2017 12:44 PM, Borislav Petkov wrote:
> On Thu, Oct 26, 2017 at 11:56:57AM -0500, Brijesh Singh wrote:
>> The variable is used as ref counter.
> 
> ... and it can't be converted to a boolean because...?
> 

SHUTDOWN command unconditionally transitions a platform to uninitialized 
state. The command does not care how many processes are actively using 
the PSP. We don't want to shutdown the firmware while other process is 
still using it.

e.g consider three processes (A, B, C)

Process A:
----------
sev_platform_init()
sev_do_cmd(..)
...
...
sev_do_cmd(..)
...
sev_platform_shutdown()

Process B:
-----------
sev_platform_init()
sev_do_cmd(...)
sev_platform_shutdown()

Process C:
----------
sev_platform_init()
sev_do_cmd(...)
sev_do_cmd(...)
sev_do_cmd(...)
sev_platform_shutdown()

As per the SEV spec section 5.1.2 (platform state machine), several 
commands require that platform should be initialized before issuing the 
actual command. As you can see Process B may finish quickly and SHUTDOWN 
from process B will simply uninitialize the firmware and cause 
unexpected result to process A and C.


>> In your previous reply you comments on global semaphore (fw_init_mutex) and
>> in response I tried to highlight why we need the global semaphore. Did I
>> misunderstood your comment ?
> 
> Yes, what happens if you get preempted while holding the mutex? Will the other
> process be able to do anything?
> 

If other process tries to issue the sev_platform_init/shutdown() then 
they have to wait.

The sev_platform_init() and sev_platform_shutdown() uses the same global 
mutex. See the original code below.

+static int __sev_platform_init(struct sev_data_init *data, int *error)
+{
+	int rc = 0;
+
+	mutex_lock(&fw_init_mutex);
+
+	if (!fw_init_count) {
+		rc = sev_do_cmd(SEV_CMD_INIT, data, error);
+		if (rc)
+			goto unlock;
+	}
+
+	fw_init_count++;
+
+unlock:
+	mutex_unlock(&fw_init_mutex);
+	return rc;
+
+}
+
+int sev_platform_shutdown(int *error)
+{
+	int rc = 0;
+
+	mutex_lock(&fw_init_mutex);
+
+	if (!fw_init_count)
+		goto unlock;
+
+	if (fw_init_count == 1) {
+		rc = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, error);
+		if (rc)
+			goto unlock;
+	}
+
+	fw_init_count--;
+
+unlock:
+	mutex_unlock(&fw_init_mutex);
+	return rc;
+}

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 19:26             ` Brijesh Singh
@ 2017-10-26 20:13               ` Borislav Petkov
  2017-10-26 20:59                 ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-26 20:13 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 26, 2017 at 02:26:15PM -0500, Brijesh Singh wrote:
> SHUTDOWN command unconditionally transitions a platform to uninitialized
> state. The command does not care how many processes are actively using the
> PSP. We don't want to shutdown the firmware while other process is still
> using it.

So why do you have to init and shutdown the PSP each time you execute a
command? Why isn't the PSP initialized, *exactly* *once* at driver init
and shut down, also exactly once at driver exit?

> If other process tries to issue the sev_platform_init/shutdown() then they
> have to wait.

Exactly, and not what you said earlier:

"If process "A" calls sev_platform_init() and if it gets preempted due
to whatever reason then we don't want another process to issue the
shutdown command while process "A" is in middle of sev_platform_init()."

IOW, if your critical regions are protected properly by a mutex, nothing
like the above will happen.

But what you're trying to explain to me is that the fw_init_count is
going to prevent a premature shutdown when it is > 1. But that's not
what I meant...

Anyway, see my question above.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 20:13               ` Borislav Petkov
@ 2017-10-26 20:59                 ` Brijesh Singh
  2017-10-27  7:56                     ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-26 20:59 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/26/2017 03:13 PM, Borislav Petkov wrote:
> On Thu, Oct 26, 2017 at 02:26:15PM -0500, Brijesh Singh wrote:
>> SHUTDOWN command unconditionally transitions a platform to uninitialized
>> state. The command does not care how many processes are actively using the
>> PSP. We don't want to shutdown the firmware while other process is still
>> using it.
> 
> So why do you have to init and shutdown the PSP each time you execute a
> command? Why isn't the PSP initialized, *exactly* *once* at driver init
> and shut down, also exactly once at driver exit?

Wish we could do that but the following reasons makes things complicated:

1) The commands must be issued from the PSP master devices, at PSP 
initialization time we do not know the PSP 'master' device. Hence we 
will not able to invoke sev_platform_init() during the PSP 
initialization time.

2) some commands require the platform to be in UNINIT state -- e.g 
FACTORY_RESET. So, if we do the INIT at the PSP initialization time then 
we still need to perform the SHUTDOWN outside the normal code flow to 
handle these commands.

we can workaround #1 by adding some hooks in sp_pci_init() to invoke the 
PSP initialization routines after pci_register_driver() is done but #2 
can get painful because it will require us calling the SHUTDOWN outside 
the sp_pci_exit() code flow.


-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-26 20:59                 ` Brijesh Singh
@ 2017-10-27  7:56                     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27  7:56 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 26, 2017 at 03:59:32PM -0500, Brijesh Singh wrote:
> we can workaround #1 by adding some hooks in sp_pci_init() to invoke the PSP
> initialization routines after pci_register_driver() is done but #2 can get
> painful because it will require us calling the SHUTDOWN outside the
> sp_pci_exit() code flow.

Ok, do that and init the PSP master and then put the device in UNINIT
state only in the functions which execute those commands which need the
device to be in UNINIT state, e.g., wrap the SEV_CMD_FACTORY_RESET glue
in a command function which does put the device in the UNINIT state as a
first step.

Then, when that function is done, put the device in the mode which the
other commands would expect it to be in, e.g., INIT state.

This way you'll simplify the whole command flow considerably and won't
have to "toggle" the device each time and will save yourself a lot of
time on command execution.

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
@ 2017-10-27  7:56                     ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27  7:56 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Thu, Oct 26, 2017 at 03:59:32PM -0500, Brijesh Singh wrote:
> we can workaround #1 by adding some hooks in sp_pci_init() to invoke the PSP
> initialization routines after pci_register_driver() is done but #2 can get
> painful because it will require us calling the SHUTDOWN outside the
> sp_pci_exit() code flow.

Ok, do that and init the PSP master and then put the device in UNINIT
state only in the functions which execute those commands which need the
device to be in UNINIT state, e.g., wrap the SEV_CMD_FACTORY_RESET glue
in a command function which does put the device in the UNINIT state as a
first step.

Then, when that function is done, put the device in the mode which the
other commands would expect it to be in, e.g., INIT state.

This way you'll simplify the whole command flow considerably and won't
have to "toggle" the device each time and will save yourself a lot of
time on command execution.

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27  7:56                     ` Borislav Petkov
  (?)
@ 2017-10-27 11:28                     ` Brijesh Singh
  2017-10-27 20:15                         ` Borislav Petkov
  -1 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-27 11:28 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/27/17 2:56 AM, Borislav Petkov wrote:
> On Thu, Oct 26, 2017 at 03:59:32PM -0500, Brijesh Singh wrote:
>> we can workaround #1 by adding some hooks in sp_pci_init() to invoke the PSP
>> initialization routines after pci_register_driver() is done but #2 can get
>> painful because it will require us calling the SHUTDOWN outside the
>> sp_pci_exit() code flow.
> Ok, do that and init the PSP master and then put the device in UNINIT
> state only in the functions which execute those commands which need the
> device to be in UNINIT state, e.g., wrap the SEV_CMD_FACTORY_RESET glue
> in a command function which does put the device in the UNINIT state as a
> first step.

transiting a platform in UINIT state to handle the FACTORY_RESET can
have a negative consequence.

Consider this scenario:

Process A
---------
sev_launch_start(...)

while (count < 10000) {
    sev_launch_update(...)
}

sev_launch_finish()
...
...

Process B:
---------
....
sev_factory_reset();
....

If in order to handle the FACTORY_RESET we  transition a platform in
UINIT state then it will results as unexpected failure from the
sev_launch_update() because the FACTORY_RESET command remove all the
state information created by sev_launch_start() etc. 

I think our design so far is simple, if command require INIT state then
caller executes sev_platform_init(), then command and finish with
sev_platform_shutdown(). If command does not require INIT state, then
simply issue the command. e.g currently, when caller issues
FACTORY_RESET then we pass command directly to PSP and if FW is in INIT
state then FACTORY_RESET returns error (INVALID_STATE/EBUSY) and we
propagate the error code to userspace.  User can retry the command
sometime later when nobody else is using the PSP.


>
> Then, when that function is done, put the device in the mode which the
> other commands would expect it to be in, e.g., INIT state.
>
> This way you'll simplify the whole command flow considerably and won't
> have to "toggle" the device each time and will save yourself a lot of
> time on command execution.
>
> Thx.
>

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 11:28                     ` Brijesh Singh
@ 2017-10-27 20:15                         ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:15 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Fri, Oct 27, 2017 at 06:28:38AM -0500, Brijesh Singh wrote:
> ... User can retry the command sometime later when nobody else is
> using the PSP.

That still doesn't prevent you from doing two things:

* make that fw_init_count a proper kref instead of your homegrown thing

* do not preemptively execute commands on the PSP if you can't possibly
know what the next command is going to be - instead, just put it in the
required state only when you really have to. I.e., don't do all that
unnecessary INIT -> CMD -> SHUTDOWN game for no reason.

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
@ 2017-10-27 20:15                         ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:15 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Fri, Oct 27, 2017 at 06:28:38AM -0500, Brijesh Singh wrote:
> ... User can retry the command sometime later when nobody else is
> using the PSP.

That still doesn't prevent you from doing two things:

* make that fw_init_count a proper kref instead of your homegrown thing

* do not preemptively execute commands on the PSP if you can't possibly
know what the next command is going to be - instead, just put it in the
required state only when you really have to. I.e., don't do all that
unnecessary INIT -> CMD -> SHUTDOWN game for no reason.

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest
  2017-10-20  2:33 ` [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
@ 2017-10-27 20:23   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:23 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:33:58PM -0500, Brijesh Singh wrote:
> A SEV-enabled guest must use ASIDs from the defined subset, while non-SEV
> guests can use the remaining ASID range. The range of 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  arch/x86/kvm/svm.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 24/38] KVM: Define SEV key management command id
  2017-10-20  2:33 ` [Part2 PATCH v6 24/38] KVM: Define SEV key management command id Brijesh Singh
@ 2017-10-27 20:23   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:23 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:33:59PM -0500, Brijesh Singh wrote:
> Define Secure Encrypted Virtualization (SEV) key management command id
> and structure. The command definition is available in SEV KM [1] spec
> 0.14 (http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf)
> and Documentation/virtual/kvm/amd-memory-encryption.txt.
> 
> 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>

Pls add my Improvements-by tag.

Also

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command
  2017-10-20  2:34 ` [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
@ 2017-10-27 20:24   ` Borislav Petkov
  2017-10-30 11:49     ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:24 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:00PM -0500, Brijesh Singh wrote:
> The command initializes the SEV platform context 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              | 132 +++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 138 insertions(+), 1 deletion(-)

...

> @@ -1167,10 +1187,18 @@ static __init int svm_hardware_setup(void)
>  	return r;
>  }
>  
> +static __exit void sev_hardware_unsetup(void)
> +{
> +	kfree(sev_asid_bitmap);
> +}
> +
>  static __exit void svm_hardware_unsetup(void)
>  {
>  	int cpu;
>  
> +	if (svm_sev_enabled())
> +		sev_hardware_unsetup();

Move that svm_sev_enabled() check into the function.

> +
>  	for_each_possible_cpu(cpu)
>  		svm_cpu_uninit(cpu);
>  
> @@ -1361,6 +1389,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);
> @@ -1443,6 +1474,28 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
>  	return 0;
>  }
>  
> +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;

You're already checking !sev_guest() below - no need to do the
svm_sev_enabled() check again.

> +
> +	asid = sev->asid;
> +	pos = asid - 1;
> +	clear_bit(pos, sev_asid_bitmap);
> +}
> +
> +static void sev_vm_destroy(struct kvm *kvm)
> +{
> +	if (!sev_guest(kvm))
> +		return;
> +
> +	sev_platform_shutdown(NULL);
> +	sev_asid_free(kvm);
> +}
> +
>  static void avic_vm_destroy(struct kvm *kvm)
>  {
>  	unsigned long flags;
> @@ -1461,6 +1514,12 @@ 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);
> +	sev_vm_destroy(kvm);
> +}
> +
>  static int avic_vm_init(struct kvm *kvm)
>  {
>  	unsigned long flags;
> @@ -5427,6 +5486,75 @@ 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;

You already checked that in svm_mem_enc_op() - no need to do it again.

> +	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_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
> +{
> +	struct kvm_sev_info *sev = &kvm->arch.sev_info;
> +	int asid, ret;
> +
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		return ret;
> +
> +	ret = -EBUSY;
> +	asid = sev_asid_new();

This operation is cheaper so do it first and then sev_platform_init()
so that in case sev_asid_new() fails, you don't "toggle" the PSP
unnecessarily.

> +	if (asid < 0)
> +		goto e_shutdown;
> +
> +	sev->active = true;
> +	sev->asid = asid;
> +
> +	return 0;
> +
> +e_shutdown:
> +	sev_platform_shutdown(&argp->error);
> +	return ret;
> +}
> +

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command
  2017-10-20  2:34 ` [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
@ 2017-10-27 20:24   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:24 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:03PM -0500, Brijesh Singh wrote:
> 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(-)

Improvements-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command
  2017-10-20  2:34 ` [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
@ 2017-10-27 20:24   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:24 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:04PM -0500, Brijesh Singh wrote:
> The command is used to retrieve the measurement of contents encrypted
> through the KVM_SEV_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 | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command
  2017-10-20  2:34 ` [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
@ 2017-10-27 20:25   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:25 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:05PM -0500, Brijesh Singh wrote:
> 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 | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command
  2017-10-20  2:34 ` [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
@ 2017-10-27 20:25   ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:25 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:06PM -0500, Brijesh Singh wrote:
> The command is used for querying the SEV guest information.
> 
> 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 | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  2017-10-20  2:34 ` [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
@ 2017-10-27 20:25   ` Borislav Petkov
  2017-10-30 13:56     ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:25 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Thu, Oct 19, 2017 at 09:34:07PM -0500, Brijesh Singh wrote:
> 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 | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 179 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 83a4d0406a4b..f19c4fb2fdc8 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -6023,6 +6023,182 @@ 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);
> +
> +		/*
> +		 * The temporary buffer may have mapping with C=0 or C=1 on x86
> +		 * side but PSP will will write the memory region with C=0.
> +		 * Lets make sure x86 cache for this memory range is flushed so
> +		 * that we can see the recent contents after the command
> +		 * completes.
> +		 */
> +		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);

arch/x86/kvm/svm.c: In function ‘svm_mem_enc_op’:
arch/x86/kvm/svm.c:6115:4: warning: argument 1 null where non-null expected [-Wnonnull]
    memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./arch/x86/include/asm/string.h:4:0,
                 from ./include/linux/string.h:18,
                 from ./include/linux/bitmap.h:8,
                 from ./include/linux/cpumask.h:11,
                 from ./arch/x86/include/asm/cpumask.h:4,
                 from ./arch/x86/include/asm/msr.h:10,
                 from ./arch/x86/include/asm/processor.h:20,
                 from ./arch/x86/include/asm/cpufeature.h:4,
                 from ./arch/x86/include/asm/thread_info.h:52,
                 from ./include/linux/thread_info.h:37,
                 from ./arch/x86/include/asm/preempt.h:6,
                 from ./include/linux/preempt.h:80,
                 from ./include/linux/hardirq.h:4,
                 from ./include/linux/kvm_host.h:10,
                 from arch/x86/kvm/svm.c:20:
./arch/x86/include/asm/string_64.h:31:14: note: in a call to function ‘memcpy’ declared here
 extern void *memcpy(void *to, const void *from, size_t len);
              ^~~~~~

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 20:15                         ` Borislav Petkov
  (?)
@ 2017-10-27 20:25                         ` Brijesh Singh
  2017-10-27 20:27                           ` Borislav Petkov
  -1 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-27 20:25 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/27/17 3:15 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 06:28:38AM -0500, Brijesh Singh wrote:
>> ... User can retry the command sometime later when nobody else is
>> using the PSP.
> That still doesn't prevent you from doing two things:
>
> * make that fw_init_count a proper kref instead of your homegrown thing

OK, I can use kref in next patch.

>
> * do not preemptively execute commands on the PSP if you can't possibly
> know what the next command is going to be - instead, just put it in the
> required state only when you really have to. I.e., don't do all that
> unnecessary INIT -> CMD -> SHUTDOWN game for no reason.

Yep, we are doing state transition only when we really need to. At least
so far I have tried to avoid making any unnecessary state transitions.

> Thx.
>

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 20:25                         ` Brijesh Singh
@ 2017-10-27 20:27                           ` Borislav Petkov
  2017-10-27 21:28                             ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 20:27 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Fri, Oct 27, 2017 at 03:25:24PM -0500, Brijesh Singh wrote:
> Yep, we are doing state transition only when we really need to. At least
> so far I have tried to avoid making any unnecessary state transitions.

So change all those which do INIT -> CMD -> SHUTDOWN to do only the
command as the INIT state is the default state, AFAIU it.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 20:27                           ` Borislav Petkov
@ 2017-10-27 21:28                             ` Brijesh Singh
  2017-10-27 21:49                               ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-27 21:28 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/27/17 3:27 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 03:25:24PM -0500, Brijesh Singh wrote:
>> Yep, we are doing state transition only when we really need to. At least
>> so far I have tried to avoid making any unnecessary state transitions.
> So change all those which do INIT -> CMD -> SHUTDOWN to do only the
> command as the INIT state is the default state, AFAIU it.
>
I don't that will work. It may be possible that I am not able to follow
what exactly you have in mind. Please let me clarify it, on boot the
firmware is in UINIT state.

Firmware maintain three states: UINIT, INIT and WORKING. Few commands
can be executed in UINIT, several command can be executed in INIT, some
command can be executed in WORKING and few commands can be executed in
any states (see SEV spec for platform state). We do not have ioctls to
issue the INIT and SHUTDOWN command.

As I have explained in previous messages, the SHUTDOWN unconditionally
destory's the FW context hence we have refrained from providing the
access for this command to userspace.

My approach is, when userspace issues a command we check if command
requires INIT state, if so then we do INIT -> CMD -> SHUTDOWN. If
command can be executed in any state then we issue the command . If
command need to be executed in UINIT state then we *do not* do
SHUTDOWN->CMD, instead we issue the cmd and PSP will fail with error
code and caller can check the error code to determine why command failed.

If I go with your recommendation then I am not able to see who will
transition the platform from UINIT -> INIT so that command can run?

Lets try with very simple example:

# modprobe ccp

/* FW is in INIT state */

# userspace runs

ioctl(fd, SEV_USER_PEK_GEN, &err)

This will fail because PEK_GEN require the platform in INIT state and
nobody has done the state transition from INIT -> UINIT.


-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 21:28                             ` Brijesh Singh
@ 2017-10-27 21:49                               ` Borislav Petkov
  2017-10-27 22:59                                 ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-27 21:49 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Fri, Oct 27, 2017 at 04:28:31PM -0500, Brijesh Singh wrote:
> This will fail because PEK_GEN require the platform in INIT state and
> nobody has done the state transition from INIT -> UINIT.

Huh, FW is in INIT state and PEK_GEN wants it to be in INIT state. Typo?

Aaanyway, I don't like this whole notion of prematurely and predictively
executing commands on the PSP if it is not needed. So how about
executing only those commands which put the FW in the required state and
then executing the actual command?

I.e., if a command needs to be executed in UINIT state, you put the PSP
in that state before executing that command. If the command needs to be
in INIT state, you put the PSP in INIT state first and so on...

For convenience, you could carry the current PSP state in some struct
psp_dev member or whatever and query it before running the respective
commands.

Hmmm?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 21:49                               ` Borislav Petkov
@ 2017-10-27 22:59                                 ` Brijesh Singh
  2017-10-28  0:00                                   ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-27 22:59 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/27/17 4:49 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 04:28:31PM -0500, Brijesh Singh wrote:
>> This will fail because PEK_GEN require the platform in INIT state and
>> nobody has done the state transition from INIT -> UINIT.
> Huh, FW is in INIT state and PEK_GEN wants it to be in INIT state. Typo?

Yes it is typo. PEK_GEN wants FW to be in INIT state hence someone need
to transition from UNINIT -> INIT.

> Aaanyway, I don't like this whole notion of prematurely and predictively
> executing commands on the PSP if it is not needed. So how about
> executing only those commands which put the FW in the required state and
> then executing the actual command?

That's what I am doing except FACTORY_RESET. The FACTORY_RESET require
the FW to be in UNINIT state,  since we don't who else is running in
parallel hence its not safe to issue the SHUTDOWN to transition from
INIT -> UNINIT. If FW is not in correct state this  command will fail
with error code (INVALID_STATE) and user can retry (please note that
user can always use PLATFORM_STATUS to query the current FW state before
issuing a command). I see that we can do a small optimization -- since
we already know the FW state hence we can avoid issuing PSP command when
we know for sure that command will fail because we are not in correct state.

>
> I.e., if a command needs to be executed in UINIT state, you put the PSP
> in that state before executing that command. If the command needs to be
> in INIT state, you put the PSP in INIT state first and so on...

If command needs INIT state and FW is not in INIT state then its safe to
transition from UNINIT -> INIT. But if command needs UNINIT state and FW
is in INIT state then its not safe to transition -- in those case we
simply return EBUSY and let the user retry the command.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-27 22:59                                 ` Brijesh Singh
@ 2017-10-28  0:00                                   ` Borislav Petkov
  2017-10-28 12:20                                     ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-28  0:00 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel

On Fri, Oct 27, 2017 at 05:59:23PM -0500, Brijesh Singh wrote:
> Yes it is typo. PEK_GEN wants FW to be in INIT state hence someone need
> to transition from UNINIT -> INIT.

Which, once you've done it once on driver init, is there.

> That's what I am doing except FACTORY_RESET.

Well, not really. Lemme pick a command at random...

PEK_CSR. For that, you do INIT -> PEK_CSR -> SHUTDOWN.

Doc says, platform needs to be in INIT or WORKING state. But nothing
says you should shut it down. Spec says, SHUTDOWN transitions platform
to UNINIT state. So when the next command comes in which needs the
platform to be in INIT state, you go and INIT it again. For no reason
*WHATSOEVER*!

I know, you're gonna say, but what if the next command needs a different
state than INIT. Well, *then* you transition it, in the command
function. When that function executes. But not before that and not in
preparation that *maybe* the next command will be it.

Now, if you did:

INIT once during driver init

PEK_CSR

(platform remains in INIT state)

<--- the next command here can execute directly if it is allowed in INIT
state.

Instead, the platform has been shutdown and you init it again. Do you
see now what I mean?

IOW, once you init the PSP master, you should keep it in the INIT state
- or the state in which most commands expect it to be and thus save
yourself all that unnecessary toggling. If a command needs it to be in a
different state, only *then* you transition it.

Instead, what you have now is that you call INIT and SHUTDOWN
around SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT,
SEV_PDH_CERT_EXPORT and for all those, the platform must be in INIT
(for some in WORKING state) but for all in INIT state and "The platform
remains be in the same state after completion." So the whole SHUTDOWN ->
INIT wankery in-between is a pure waste of electrons.

>  I see that we can do a small optimization -- since we already know
> the FW state hence we can avoid issuing PSP command when we know for
> sure that command will fail because we are not in correct state.

As I said before, you should do that regardless by recording the current
state of the PSP in variable so that you can save yourself the status
querying.

> If command needs INIT state and FW is not in INIT state then its safe to
> transition from UNINIT -> INIT. But if command needs UNINIT state and FW
> is in INIT state then its not safe to transition -- in those case we
> simply return EBUSY and let the user retry the command.

Whatever - that doesn't contradict what I'm proposing.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-28  0:00                                   ` Borislav Petkov
@ 2017-10-28 12:20                                     ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-28 12:20 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, linux-kernel



On 10/27/17 7:00 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 05:59:23PM -0500, Brijesh Singh wrote:
>> Yes it is typo. PEK_GEN wants FW to be in INIT state hence someone need
>> to transition from UNINIT -> INIT.
> Which, once you've done it once on driver init, is there.
>
>> That's what I am doing except FACTORY_RESET.
> Well, not really. Lemme pick a command at random...
>
> PEK_CSR. For that, you do INIT -> PEK_CSR -> SHUTDOWN.
>
> Doc says, platform needs to be in INIT or WORKING state. But nothing
> says you should shut it down. Spec says, SHUTDOWN transitions platform
> to UNINIT state. So when the next command comes in which needs the
> platform to be in INIT state, you go and INIT it again. For no reason
> *WHATSOEVER*!
>
> I know, you're gonna say, but what if the next command needs a different
> state than INIT. Well, *then* you transition it, in the command
> function. When that function executes. But not before that and not in
> preparation that *maybe* the next command will be it.
>
> Now, if you did:
>
> INIT once during driver init
>
> PEK_CSR
>
> (platform remains in INIT state)
>
> <--- the next command here can execute directly if it is allowed in INIT
> state.
>
> Instead, the platform has been shutdown and you init it again. Do you
> see now what I mean?

Yes, I can see that with your proposal we may able to save some PSP
interaction because after command execution we do not restore to the
previous state. e.g before executing the PEK_CSR command if FW was in
UINIT then we do UNINIT -> INIT and leave it to INIT state.

> IOW, once you init the PSP master, you should keep it in the INIT state
> - or the state in which most commands expect it to be and thus save
> yourself all that unnecessary toggling. If a command needs it to be in a
> different state, only *then* you transition it.

Let me implement it and send you the patch. I think the command
execution function will look like this:

static int sev_ioctl_do_pek_csr(...)
{
   ....
   ....
   mutex(&fw_init_mutex);

   /* If FW is not in INIT state then initialize before executing command */
   if (psp->sev_state != SEV_STATE_INIT) {
       rc = sev_platform_init(...);
       if (rc) {
         mutex_unlock(&fw_init_mutex);
         return rc;
       }
    }
   
     rc = sev_do_cmd(....)

     mutex_unlock(&fw_init_mutex);

     return rc;
}

and factory reset will look like this

static int sev_ioctl_do_reset(...)
{
   mutex(&fw_init_mutex);

   /* If FW is not in UINIT state then shutdown before executing command */
   if (psp->sev_state != SEV_STATE_INIT)
       sev_platform_shutdown(...);
  
    rc = sev_do_cmd(....)

    mutex_unlock(&fw_init_mutex);

    return rc;
}

> Instead, what you have now is that you call INIT and SHUTDOWN
> around SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT,
> SEV_PDH_CERT_EXPORT and for all those, the platform must be in INIT
> (for some in WORKING state) but for all in INIT state and "The platform
> remains be in the same state after completion." So the whole SHUTDOWN ->
> INIT wankery in-between is a pure waste of electrons.
>
>>  I see that we can do a small optimization -- since we already know
>> the FW state hence we can avoid issuing PSP command when we know for
>> sure that command will fail because we are not in correct state.
> As I said before, you should do that regardless by recording the current
> state of the PSP in variable so that you can save yourself the status
> querying.
>
>> If command needs INIT state and FW is not in INIT state then its safe to
>> transition from UNINIT -> INIT. But if command needs UNINIT state and FW
>> is in INIT state then its not safe to transition -- in those case we
>> simply return EBUSY and let the user retry the command.
> Whatever - that doesn't contradict what I'm proposing.
>

^ permalink raw reply	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
  2017-10-23  7:34     ` Borislav Petkov
  2017-10-23  9:20     ` Borislav Petkov
@ 2017-10-29 20:48   ` Brijesh Singh
  2017-10-29 21:14     ` Brijesh Singh
  2017-10-30 17:21     ` Borislav Petkov
  2 siblings, 2 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-29 20:48 UTC (permalink / raw)
  To: bp
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the 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 API to communicate with the SEV firmware. The API can be
   used by the hypervisor to create encryption context for a SEV guest.

 - a 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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---

Boris,

I have tried to minimize the INIT -> SHUTDOWN transition by keeping state
information in sev_state variable. Since we INIT the platform during the
modprobe time hence we no longer need the kref count and init mutex.
Here are list of changes.

Changes since v6:
 * Add functions to init and shutdown firmware during modprobe
 * Add sev_state variable in psp_device to keep track of the INIT and SHUTDOWN
   state
 * Don't allow caller to shutdown the FW because SHUTDOWN will be done during
   the module removal.
 * Drop the fw_init_mutex and init_refcount because we no longer allow apps to
   INIT and UINIT the platform

 drivers/crypto/ccp/psp-dev.c | 360 +++++++++++++++++++++++++++++++++++++++++++
 drivers/crypto/ccp/psp-dev.h |  22 +++
 drivers/crypto/ccp/sp-dev.c  |   9 ++
 drivers/crypto/ccp/sp-dev.h  |   4 +
 include/linux/psp-sev.h      | 158 +++++++++++++++++++
 5 files changed, 553 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index b5789f878560..060f57ac08b3 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -26,6 +26,15 @@
 #include "sp-dev.h"
 #include "psp-dev.h"
 
+#define DEVICE_NAME	"sev"
+
+static DEFINE_MUTEX(sev_cmd_mutex);
+static struct sev_misc_dev *misc_dev;
+static struct psp_device *psp_master;
+
+static int sev_platform_shutdown_locked(int *error);
+static int sev_platform_init_locked(struct sev_data_init *data, int *error);
+
 static struct psp_device *psp_alloc_struct(struct sp_device *sp)
 {
 	struct device *dev = sp->dev;
@@ -45,9 +54,304 @@ static struct psp_device *psp_alloc_struct(struct sp_device *sp)
 
 static irqreturn_t psp_irq_handler(int irq, void *data)
 {
+	struct psp_device *psp = data;
+	unsigned int status;
+	int reg;
+
+	/* Read the interrupt status: */
+	status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
+
+	/* Check if it is command completion: */
+	if (!(status & BIT(PSP_CMD_COMPLETE_REG)))
+		goto done;
+
+	/* Check if it is 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);
+	}
+
+done:
+	/* Clear the interrupt status by writing the same value we read. */
+	iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
+
 	return IRQ_HANDLED;
 }
 
+static void 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);
+}
+
+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_user_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_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:		return sizeof(struct sev_data_dbg);
+	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_FINISH:		return sizeof(struct sev_data_receive_finish);
+	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_LAUNCH_UPDATE_SECRET:	return sizeof(struct sev_data_launch_secret);
+	default:				return 0;
+	}
+
+	return 0;
+}
+
+static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
+{
+	struct psp_device *psp = psp_master;
+	unsigned int phys_lsb, phys_msb;
+	unsigned int reg, ret = 0;
+
+	if (!psp)
+		return -ENODEV;
+
+	/* Get the physical address of the command buffer */
+	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);
+
+	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 |= PSP_CMDRESP_IOC;
+	iowrite32(reg, psp->io_regs + PSP_CMDRESP);
+
+	/* wait for command completion */
+	sev_wait_cmd_ioc(psp, &reg);
+
+	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;
+	}
+
+	print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+			     sev_cmd_buffer_len(cmd), false);
+
+	return ret;
+}
+
+static int sev_do_cmd(int cmd, void *data, int *psp_ret)
+{
+	int rc;
+
+	mutex_lock(&sev_cmd_mutex);
+	rc = sev_do_cmd_locked(cmd, data, psp_ret);
+	mutex_unlock(&sev_cmd_mutex);
+
+	return rc;
+}
+
+static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
+{
+	return -ENOTTY;
+}
+
+static const struct file_operations sev_fops = {
+	.owner	= THIS_MODULE,
+	.unlocked_ioctl = sev_ioctl,
+};
+
+static int sev_platform_init_locked(struct sev_data_init *data, int *error)
+{
+	struct psp_device *psp = psp_master;
+	struct sev_data_init *input = NULL;
+	int rc = 0;
+
+	if (!psp)
+		return -ENODEV;
+
+	if (psp->sev_state == SEV_STATE_INIT)
+		return 0;
+
+	if (!data) {
+		input = kzalloc(sizeof(*input), GFP_KERNEL);
+		if (!input)
+			return -ENOMEM;
+
+		data = input;
+	}
+
+	rc = sev_do_cmd_locked(SEV_CMD_INIT, data, error);
+	if (rc)
+		goto e_free;
+
+	psp->sev_state = SEV_STATE_INIT;
+	dev_dbg(psp->dev, "SEV firmware intialized\n");
+
+e_free:
+	kfree(input);
+	return rc;
+}
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+	int rc;
+
+	mutex_lock(&sev_cmd_mutex);
+	rc = sev_platform_init_locked(data, error);
+	mutex_unlock(&sev_cmd_mutex);
+
+	return rc;
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+static int sev_platform_shutdown_locked(int *error)
+{
+	int ret;
+
+	ret = sev_do_cmd_locked(SEV_CMD_SHUTDOWN, 0, error);
+	if (ret)
+		return ret;
+
+	psp_master->sev_state = SEV_STATE_UNINIT;
+	dev_dbg(psp_master->dev, "SEV firmware shutdown\n");
+
+	return ret;
+}
+
+int sev_platform_shutdown(int *error)
+{
+	if (error)
+		*error = 0;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_user_data_status *data, int *error)
+{
+	return sev_do_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_do_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_do_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_do_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_do_cmd(SEV_CMD_DECOMMISSION, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_decommission);
+
+int sev_guest_df_flush(int *error)
+{
+	return sev_do_cmd(SEV_CMD_DF_FLUSH, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_df_flush);
+
+static int sev_ops_init(struct psp_device *psp)
+{
+	struct device *dev = psp->dev;
+	int ret;
+
+	/*
+	 * SEV feature support can be detected on multiple devices but the SEV
+	 * FW commands must be issued on the master. During probe, we do not
+	 * know the master hence we create /dev/sev on the first device probe.
+	 * sev_do_cmd() finds the right master device to which to issue the
+	 * command to the firmware.
+	 */
+	if (!misc_dev) {
+		struct miscdevice *misc;
+
+		misc_dev = devm_kzalloc(dev, sizeof(*misc_dev), GFP_KERNEL);
+		if (!misc_dev)
+			return -ENOMEM;
+
+		misc = &misc_dev->misc;
+		misc->minor = MISC_DYNAMIC_MINOR;
+		misc->name = DEVICE_NAME;
+		misc->fops = &sev_fops;
+
+		ret = misc_register(misc);
+		if (ret)
+			return ret;
+
+		kref_init(&misc_dev->refcount);
+	} else {
+		kref_get(&misc_dev->refcount);
+	}
+
+	init_waitqueue_head(&psp->sev_int_queue);
+	psp->sev_misc = misc_dev;
+	dev_dbg(dev, "registered SEV device\n");
+
+	return 0;
+}
+
+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 kref *ref)
+{
+	struct sev_misc_dev *misc_dev = container_of(ref, struct sev_misc_dev, refcount);
+
+	misc_deregister(&misc_dev->misc);
+}
+
 int psp_dev_init(struct sp_device *sp)
 {
 	struct device *dev = sp->dev;
@@ -84,11 +388,17 @@ int psp_dev_init(struct sp_device *sp)
 	if (sp->set_psp_master_device)
 		sp->set_psp_master_device(sp);
 
+	ret = sev_init(psp);
+	if (ret)
+		goto e_irq;
+
 	/* Enable interrupt */
 	iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
 
 	return 0;
 
+e_irq:
+	sp_free_psp_irq(psp->sp, psp);
 e_err:
 	sp->psp_data = NULL;
 
@@ -101,5 +411,55 @@ void psp_dev_destroy(struct sp_device *sp)
 {
 	struct psp_device *psp = sp->psp_data;
 
+	if (psp->sev_misc)
+		kref_put(&misc_dev->refcount, sev_exit);
+
 	sp_free_psp_irq(sp, psp);
 }
+
+void psp_pci_init(void)
+{
+	struct sev_user_data_status *data;
+	struct sp_device *sp;
+	int error, rc;
+
+	sp = sp_get_psp_master_device();
+	if (!sp)
+		return;
+
+	psp_master = sp->psp_data;
+
+	/* Initialize the platform */
+	rc = sev_platform_init(NULL, &error);
+	if (rc) {
+		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
+		return;
+	}
+
+	/* Display SEV firmware version */
+	data = kzalloc(sizeof (*data), GFP_KERNEL);
+	if (!data)
+		return;
+
+	rc = sev_platform_status(data, &error);
+	if (rc) {
+		dev_err(sp->dev, "SEV: failed to get status error %#x\n", error);
+		goto e_free;
+	}
+
+	dev_info(sp->dev, "SEV API:%d.%d build:%d\n",
+		 data->api_major, data->api_minor, data->build);
+
+e_free:
+	kfree(data);
+}
+
+void psp_pci_exit(void)
+{
+	if (!psp_master)
+		return;
+
+	mutex_lock(&sev_cmd_mutex);
+	sev_platform_shutdown_locked(NULL);
+	mutex_unlock(&sev_cmd_mutex);
+}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 55b7808367c3..98889b721904 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
 
@@ -44,6 +56,11 @@
 
 #define MAX_PSP_NAME_LEN		16
 
+struct sev_misc_dev {
+	struct kref refcount;
+	struct miscdevice misc;
+};
+
 struct psp_device {
 	struct list_head entry;
 
@@ -54,6 +71,11 @@ struct psp_device {
 	struct sp_device *sp;
 
 	void __iomem *io_regs;
+
+	int sev_state;
+	unsigned int sev_int_rcvd;
+	wait_queue_head_t sev_int_queue;
+	struct sev_misc_dev *sev_misc;
 };
 
 #endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index cf101c039c8f..eb0da6572720 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -272,6 +272,10 @@ static int __init sp_mod_init(void)
 	if (ret)
 		return ret;
 
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+	psp_pci_init();
+#endif
+
 	return 0;
 #endif
 
@@ -291,6 +295,11 @@ static int __init sp_mod_init(void)
 static void __exit sp_mod_exit(void)
 {
 #ifdef CONFIG_X86
+
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+	psp_pci_exit();
+#endif
+
 	sp_pci_exit();
 #endif
 
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 909cf3e436b4..acb197b66ced 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -143,12 +143,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
 #ifdef CONFIG_CRYPTO_DEV_SP_PSP
 
 int psp_dev_init(struct sp_device *sp);
+void psp_pci_init(void);
 void psp_dev_destroy(struct sp_device *sp);
+void psp_pci_exit(void);
 
 #else /* !CONFIG_CRYPTO_DEV_SP_PSP */
 
 static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_pci_init(void) { }
 static inline void psp_dev_destroy(struct sp_device *sp) { }
+static inline void psp_pci_exit(void) { }
 
 #endif /* CONFIG_CRYPTO_DEV_SP_PSP */
 
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 15bda519538e..7ddce7dec464 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -491,4 +491,162 @@ struct sev_data_dbg {
 	u32 len;				/* In */
 } __packed;
 
+#ifdef 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
+ *
+ * @status: sev_user_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_user_data_status *status, int *error);
+
+/**
+ * sev_issue_cmd_external_user - issue SEV command by other driver with a file
+ * handle.
+ *
+ * This function can be used by other drivers to issue a SEV command on
+ * behalf of userspace. The caller must pass a valid SEV file descriptor
+ * so that we know that it 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_user_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_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; }
+
+static inline int
+sev_issue_cmd_external_user(struct file *filep,
+			    unsigned int id, void *data, int *error)
+{
+	return -ENODEV;
+}
+
+#endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
+
 #endif	/* __PSP_SEV_H__ */
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-29 20:48   ` [Part2 PATCH v6.1 16/38] " Brijesh Singh
@ 2017-10-29 21:14     ` Brijesh Singh
  2017-10-30 17:21     ` Borislav Petkov
  1 sibling, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-29 21:14 UTC (permalink / raw)
  To: bp
  Cc: brijesh.singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

I just realized that this should be marked as "PATCH v6.1 13/38 ...". I
had some  debug patch before this hence it was pushed below in the stack.


On 10/29/17 3:48 PM, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the 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 API to communicate with the SEV firmware. The API can be
>    used by the hypervisor to create encryption context for a SEV guest.
>
>  - a 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
> Improvements-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>
> Boris,
>
> I have tried to minimize the INIT -> SHUTDOWN transition by keeping state
> information in sev_state variable. Since we INIT the platform during the
> modprobe time hence we no longer need the kref count and init mutex.
> Here are list of changes.
>
> Changes since v6:
>  * Add functions to init and shutdown firmware during modprobe
>  * Add sev_state variable in psp_device to keep track of the INIT and SHUTDOWN
>    state
>  * Don't allow caller to shutdown the FW because SHUTDOWN will be done during
>    the module removal.
>  * Drop the fw_init_mutex and init_refcount because we no longer allow apps to
>    INIT and UINIT the platform
>
>  drivers/crypto/ccp/psp-dev.c | 360 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/crypto/ccp/psp-dev.h |  22 +++
>  drivers/crypto/ccp/sp-dev.c  |   9 ++
>  drivers/crypto/ccp/sp-dev.h  |   4 +
>  include/linux/psp-sev.h      | 158 +++++++++++++++++++
>  5 files changed, 553 insertions(+)
>
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index b5789f878560..060f57ac08b3 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -26,6 +26,15 @@
>  #include "sp-dev.h"
>  #include "psp-dev.h"
>  
> +#define DEVICE_NAME	"sev"
> +
> +static DEFINE_MUTEX(sev_cmd_mutex);
> +static struct sev_misc_dev *misc_dev;
> +static struct psp_device *psp_master;
> +
> +static int sev_platform_shutdown_locked(int *error);
> +static int sev_platform_init_locked(struct sev_data_init *data, int *error);
> +
>  static struct psp_device *psp_alloc_struct(struct sp_device *sp)
>  {
>  	struct device *dev = sp->dev;
> @@ -45,9 +54,304 @@ static struct psp_device *psp_alloc_struct(struct sp_device *sp)
>  
>  static irqreturn_t psp_irq_handler(int irq, void *data)
>  {
> +	struct psp_device *psp = data;
> +	unsigned int status;
> +	int reg;
> +
> +	/* Read the interrupt status: */
> +	status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
> +
> +	/* Check if it is command completion: */
> +	if (!(status & BIT(PSP_CMD_COMPLETE_REG)))
> +		goto done;
> +
> +	/* Check if it is 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);
> +	}
> +
> +done:
> +	/* Clear the interrupt status by writing the same value we read. */
> +	iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
> +
>  	return IRQ_HANDLED;
>  }
>  
> +static void 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);
> +}
> +
> +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_user_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_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:		return sizeof(struct sev_data_dbg);
> +	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_FINISH:		return sizeof(struct sev_data_receive_finish);
> +	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_LAUNCH_UPDATE_SECRET:	return sizeof(struct sev_data_launch_secret);
> +	default:				return 0;
> +	}
> +
> +	return 0;
> +}
> +
> +static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
> +{
> +	struct psp_device *psp = psp_master;
> +	unsigned int phys_lsb, phys_msb;
> +	unsigned int reg, ret = 0;
> +
> +	if (!psp)
> +		return -ENODEV;
> +
> +	/* Get the physical address of the command buffer */
> +	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);
> +
> +	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 |= PSP_CMDRESP_IOC;
> +	iowrite32(reg, psp->io_regs + PSP_CMDRESP);
> +
> +	/* wait for command completion */
> +	sev_wait_cmd_ioc(psp, &reg);
> +
> +	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;
> +	}
> +
> +	print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> +			     sev_cmd_buffer_len(cmd), false);
> +
> +	return ret;
> +}
> +
> +static int sev_do_cmd(int cmd, void *data, int *psp_ret)
> +{
> +	int rc;
> +
> +	mutex_lock(&sev_cmd_mutex);
> +	rc = sev_do_cmd_locked(cmd, data, psp_ret);
> +	mutex_unlock(&sev_cmd_mutex);
> +
> +	return rc;
> +}
> +
> +static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> +{
> +	return -ENOTTY;
> +}
> +
> +static const struct file_operations sev_fops = {
> +	.owner	= THIS_MODULE,
> +	.unlocked_ioctl = sev_ioctl,
> +};
> +
> +static int sev_platform_init_locked(struct sev_data_init *data, int *error)
> +{
> +	struct psp_device *psp = psp_master;
> +	struct sev_data_init *input = NULL;
> +	int rc = 0;
> +
> +	if (!psp)
> +		return -ENODEV;
> +
> +	if (psp->sev_state == SEV_STATE_INIT)
> +		return 0;
> +
> +	if (!data) {
> +		input = kzalloc(sizeof(*input), GFP_KERNEL);
> +		if (!input)
> +			return -ENOMEM;
> +
> +		data = input;
> +	}
> +
> +	rc = sev_do_cmd_locked(SEV_CMD_INIT, data, error);
> +	if (rc)
> +		goto e_free;
> +
> +	psp->sev_state = SEV_STATE_INIT;
> +	dev_dbg(psp->dev, "SEV firmware intialized\n");
> +
> +e_free:
> +	kfree(input);
> +	return rc;
> +}
> +
> +int sev_platform_init(struct sev_data_init *data, int *error)
> +{
> +	int rc;
> +
> +	mutex_lock(&sev_cmd_mutex);
> +	rc = sev_platform_init_locked(data, error);
> +	mutex_unlock(&sev_cmd_mutex);
> +
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(sev_platform_init);
> +
> +static int sev_platform_shutdown_locked(int *error)
> +{
> +	int ret;
> +
> +	ret = sev_do_cmd_locked(SEV_CMD_SHUTDOWN, 0, error);
> +	if (ret)
> +		return ret;
> +
> +	psp_master->sev_state = SEV_STATE_UNINIT;
> +	dev_dbg(psp_master->dev, "SEV firmware shutdown\n");
> +
> +	return ret;
> +}
> +
> +int sev_platform_shutdown(int *error)
> +{
> +	if (error)
> +		*error = 0;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(sev_platform_shutdown);
> +
> +int sev_platform_status(struct sev_user_data_status *data, int *error)
> +{
> +	return sev_do_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_do_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_do_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_do_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_do_cmd(SEV_CMD_DECOMMISSION, data, error);
> +}
> +EXPORT_SYMBOL_GPL(sev_guest_decommission);
> +
> +int sev_guest_df_flush(int *error)
> +{
> +	return sev_do_cmd(SEV_CMD_DF_FLUSH, 0, error);
> +}
> +EXPORT_SYMBOL_GPL(sev_guest_df_flush);
> +
> +static int sev_ops_init(struct psp_device *psp)
> +{
> +	struct device *dev = psp->dev;
> +	int ret;
> +
> +	/*
> +	 * SEV feature support can be detected on multiple devices but the SEV
> +	 * FW commands must be issued on the master. During probe, we do not
> +	 * know the master hence we create /dev/sev on the first device probe.
> +	 * sev_do_cmd() finds the right master device to which to issue the
> +	 * command to the firmware.
> +	 */
> +	if (!misc_dev) {
> +		struct miscdevice *misc;
> +
> +		misc_dev = devm_kzalloc(dev, sizeof(*misc_dev), GFP_KERNEL);
> +		if (!misc_dev)
> +			return -ENOMEM;
> +
> +		misc = &misc_dev->misc;
> +		misc->minor = MISC_DYNAMIC_MINOR;
> +		misc->name = DEVICE_NAME;
> +		misc->fops = &sev_fops;
> +
> +		ret = misc_register(misc);
> +		if (ret)
> +			return ret;
> +
> +		kref_init(&misc_dev->refcount);
> +	} else {
> +		kref_get(&misc_dev->refcount);
> +	}
> +
> +	init_waitqueue_head(&psp->sev_int_queue);
> +	psp->sev_misc = misc_dev;
> +	dev_dbg(dev, "registered SEV device\n");
> +
> +	return 0;
> +}
> +
> +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 kref *ref)
> +{
> +	struct sev_misc_dev *misc_dev = container_of(ref, struct sev_misc_dev, refcount);
> +
> +	misc_deregister(&misc_dev->misc);
> +}
> +
>  int psp_dev_init(struct sp_device *sp)
>  {
>  	struct device *dev = sp->dev;
> @@ -84,11 +388,17 @@ int psp_dev_init(struct sp_device *sp)
>  	if (sp->set_psp_master_device)
>  		sp->set_psp_master_device(sp);
>  
> +	ret = sev_init(psp);
> +	if (ret)
> +		goto e_irq;
> +
>  	/* Enable interrupt */
>  	iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
>  
>  	return 0;
>  
> +e_irq:
> +	sp_free_psp_irq(psp->sp, psp);
>  e_err:
>  	sp->psp_data = NULL;
>  
> @@ -101,5 +411,55 @@ void psp_dev_destroy(struct sp_device *sp)
>  {
>  	struct psp_device *psp = sp->psp_data;
>  
> +	if (psp->sev_misc)
> +		kref_put(&misc_dev->refcount, sev_exit);
> +
>  	sp_free_psp_irq(sp, psp);
>  }
> +
> +void psp_pci_init(void)
> +{
> +	struct sev_user_data_status *data;
> +	struct sp_device *sp;
> +	int error, rc;
> +
> +	sp = sp_get_psp_master_device();
> +	if (!sp)
> +		return;
> +
> +	psp_master = sp->psp_data;
> +
> +	/* Initialize the platform */
> +	rc = sev_platform_init(NULL, &error);
> +	if (rc) {
> +		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
> +		return;
> +	}
> +
> +	/* Display SEV firmware version */
> +	data = kzalloc(sizeof (*data), GFP_KERNEL);
> +	if (!data)
> +		return;
> +
> +	rc = sev_platform_status(data, &error);
> +	if (rc) {
> +		dev_err(sp->dev, "SEV: failed to get status error %#x\n", error);
> +		goto e_free;
> +	}
> +
> +	dev_info(sp->dev, "SEV API:%d.%d build:%d\n",
> +		 data->api_major, data->api_minor, data->build);
> +
> +e_free:
> +	kfree(data);
> +}
> +
> +void psp_pci_exit(void)
> +{
> +	if (!psp_master)
> +		return;
> +
> +	mutex_lock(&sev_cmd_mutex);
> +	sev_platform_shutdown_locked(NULL);
> +	mutex_unlock(&sev_cmd_mutex);
> +}
> diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
> index 55b7808367c3..98889b721904 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
>  
> @@ -44,6 +56,11 @@
>  
>  #define MAX_PSP_NAME_LEN		16
>  
> +struct sev_misc_dev {
> +	struct kref refcount;
> +	struct miscdevice misc;
> +};
> +
>  struct psp_device {
>  	struct list_head entry;
>  
> @@ -54,6 +71,11 @@ struct psp_device {
>  	struct sp_device *sp;
>  
>  	void __iomem *io_regs;
> +
> +	int sev_state;
> +	unsigned int sev_int_rcvd;
> +	wait_queue_head_t sev_int_queue;
> +	struct sev_misc_dev *sev_misc;
>  };
>  
>  #endif /* __PSP_DEV_H */
> diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
> index cf101c039c8f..eb0da6572720 100644
> --- a/drivers/crypto/ccp/sp-dev.c
> +++ b/drivers/crypto/ccp/sp-dev.c
> @@ -272,6 +272,10 @@ static int __init sp_mod_init(void)
>  	if (ret)
>  		return ret;
>  
> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
> +	psp_pci_init();
> +#endif
> +
>  	return 0;
>  #endif
>  
> @@ -291,6 +295,11 @@ static int __init sp_mod_init(void)
>  static void __exit sp_mod_exit(void)
>  {
>  #ifdef CONFIG_X86
> +
> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
> +	psp_pci_exit();
> +#endif
> +
>  	sp_pci_exit();
>  #endif
>  
> diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
> index 909cf3e436b4..acb197b66ced 100644
> --- a/drivers/crypto/ccp/sp-dev.h
> +++ b/drivers/crypto/ccp/sp-dev.h
> @@ -143,12 +143,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
>  #ifdef CONFIG_CRYPTO_DEV_SP_PSP
>  
>  int psp_dev_init(struct sp_device *sp);
> +void psp_pci_init(void);
>  void psp_dev_destroy(struct sp_device *sp);
> +void psp_pci_exit(void);
>  
>  #else /* !CONFIG_CRYPTO_DEV_SP_PSP */
>  
>  static inline int psp_dev_init(struct sp_device *sp) { return 0; }
> +static inline void psp_pci_init(void) { }
>  static inline void psp_dev_destroy(struct sp_device *sp) { }
> +static inline void psp_pci_exit(void) { }
>  
>  #endif /* CONFIG_CRYPTO_DEV_SP_PSP */
>  
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 15bda519538e..7ddce7dec464 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -491,4 +491,162 @@ struct sev_data_dbg {
>  	u32 len;				/* In */
>  } __packed;
>  
> +#ifdef 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
> + *
> + * @status: sev_user_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_user_data_status *status, int *error);
> +
> +/**
> + * sev_issue_cmd_external_user - issue SEV command by other driver with a file
> + * handle.
> + *
> + * This function can be used by other drivers to issue a SEV command on
> + * behalf of userspace. The caller must pass a valid SEV file descriptor
> + * so that we know that it 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_user_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_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; }
> +
> +static inline int
> +sev_issue_cmd_external_user(struct file *filep,
> +			    unsigned int id, void *data, int *error)
> +{
> +	return -ENODEV;
> +}
> +
> +#endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
> +
>  #endif	/* __PSP_SEV_H__ */

^ permalink raw reply	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
  2017-10-23  7:42     ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
@ 2017-10-29 21:16   ` Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-29 21:16 UTC (permalink / raw)
  To: bp
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_FACTORY_RESET command can be used by the platform owner to
reset the non-volatile SEV related data. The command is defined in
SEV spec section 5.4

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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Gary R Hook <gary.hook@amd.com>
---

Boris,

It may look confusing that we call PLATFORM_STATUS command to check the
current FW state even when we keep the state in psp->sev_state.
Per spec, PLATFORM_INIT transitions FW from UINIT -> INIT and SHUTDOWN from
<ANY_STATE> -> UINIT but there are multiple commands which can transition FW
from INIT -> WORKING state. Hence my thinking is, if we really need to know
whether we are in WORKING state then invoke PLATFORM_STATUS. So far,
FACTORY_RESET is where we need to know if we are in WORKING state to avoid
shutdown the FW. In real world app this command may not be used that
often hence I don't feel like adding more complexity to the code.

Changes since v6:
 * If FW is in WORKING state then reject the command
 * If FW is in INIT state then shutdown before issuing the command


 drivers/crypto/ccp/psp-dev.c | 77 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 060f57ac08b3..b02ea56508b4 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -177,9 +177,84 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
 	return rc;
 }
 
+static int sev_platform_state(int *state, int *error)
+{
+	struct sev_user_data_status *data;
+	int rc;
+
+	data = kzalloc(sizeof (*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	rc = sev_do_cmd_locked(SEV_CMD_PLATFORM_STATUS, data, error);
+	if (rc)
+		goto e_free;
+
+	*state = data->state;
+
+e_free:
+	kfree(data);
+	return rc;
+}
+
+static int sev_ioctl_do_reset(struct sev_issue_cmd *argp)
+{
+	int state, rc;
+
+	rc = sev_platform_state(&state, &argp->error);
+	if (rc)
+		return rc;
+
+	if (state == SEV_STATE_WORKING) {
+		argp->error = SEV_RET_INVALID_PLATFORM_STATE;
+		return -EBUSY;
+	}
+
+	if (state == SEV_STATE_INIT) {
+		rc = sev_platform_shutdown_locked(&argp->error);
+		if (rc)
+			return rc;
+	}
+
+	return sev_do_cmd_locked(SEV_CMD_FACTORY_RESET, 0, &argp->error);
+}
+
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
-	return -ENOTTY;
+	void __user *argp = (void __user *)arg;
+	struct sev_issue_cmd input;
+	int ret = -EFAULT;
+
+	if (!psp_master)
+		return -ENODEV;
+
+	if (ioctl != SEV_ISSUE_CMD)
+		return -EINVAL;
+
+	if (copy_from_user(&input, argp, sizeof(struct sev_issue_cmd)))
+		return -EFAULT;
+
+	if (input.cmd > SEV_MAX)
+		return -EINVAL;
+
+	mutex_lock(&sev_cmd_mutex);
+
+	switch (input.cmd) {
+
+	case SEV_FACTORY_RESET:
+		ret = sev_ioctl_do_reset(&input);
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
+		ret = -EFAULT;
+out:
+	mutex_unlock(&sev_cmd_mutex);
+
+	return ret;
 }
 
 static const struct file_operations sev_fops = {
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.1 15/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command
  2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
  2017-10-23  8:48   ` Borislav Petkov
  2017-10-24 18:41   ` Gary R Hook
@ 2017-10-30  3:13   ` Brijesh Singh
  2 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30  3:13 UTC (permalink / raw)
  To: bp
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.

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
Reviewed-by: Borislav Petkov <bp@suse.de>
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Gary R Hook <gary.hook@amd.com>
---

Boris,

I had your R-b in v6 and have kept it. The changes in this patch are
very minor. Let me know if you are okay with it - thanks

Changes since v6:
 * use psp->sev_state to check if FW is in correct state before
   doing the INIT transition

 drivers/crypto/ccp/psp-dev.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 24a970809ded..53fbbc41b521 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -240,6 +240,19 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
+{
+	int rc;
+
+	if (psp_master->sev_state == SEV_STATE_UNINIT) {
+		rc = sev_platform_init_locked(NULL, &argp->error);
+		if (rc)
+			return rc;
+	}
+
+	return sev_do_cmd_locked(cmd, 0, &argp->error);
+}
+
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
 	void __user *argp = (void __user *)arg;
@@ -268,6 +281,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PLATFORM_STATUS:
 		ret = sev_ioctl_do_platform_status(&input);
 		break;
+	case SEV_PEK_GEN:
+		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [Part2 PATCH v6.2 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command
  2017-10-23 22:10   ` [Part2 PATCH v6.1 " Brijesh Singh
  2017-10-24 18:42     ` Gary R Hook
@ 2017-10-30  3:23     ` Brijesh Singh
  1 sibling, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30  3:23 UTC (permalink / raw)
  To: bp
  Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
	Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
	linux-crypto, kvm, linux-kernel

The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.

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
Improvements-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Gary R Hook <gary.hook@amd.com>
---

Changes since v6.1:
 * use psp->sev_state to check the state before transition to INIT

 drivers/crypto/ccp/psp-dev.c | 68 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 0d4d95bc35ab..e69ac6f6173c 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -253,6 +253,71 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
 	return sev_do_cmd_locked(cmd, 0, &argp->error);
 }
 
+static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_pek_csr input;
+	struct sev_data_pek_csr *data;
+	void *blob = NULL;
+	int ret;
+
+	if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+		return -EFAULT;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	/* userspace wants to query CSR length */
+	if (!input.address || !input.length)
+		goto cmd;
+
+	/* allocate a physically contiguous buffer to store the CSR blob */
+	if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
+	    input.length > SEV_FW_BLOB_MAX_SIZE) {
+		ret = -EFAULT;
+		goto e_free;
+	}
+
+	blob = kmalloc(input.length, GFP_KERNEL);
+	if (!blob) {
+		ret = -ENOMEM;
+		goto e_free;
+	}
+
+	data->address = __psp_pa(blob);
+	data->len = input.length;
+
+cmd:
+	if (psp_master->sev_state == SEV_STATE_UNINIT) {
+		ret = sev_platform_init_locked(NULL, &argp->error);
+		if (ret)
+			goto e_free_blob;
+	}
+
+	ret = sev_do_cmd_locked(SEV_CMD_PEK_CSR, data, &argp->error);
+
+	/*
+	 * If we query the CSR length, FW responded with expected data
+	 */
+	input.length = data->len;
+
+	if (copy_to_user((void __user *)argp->data, &input, sizeof(input))) {
+		ret = -EFAULT;
+		goto e_free_blob;
+	}
+
+	if (blob) {
+		if (copy_to_user((void __user *)input.address, blob, input.length))
+			ret = -EFAULT;
+	}
+
+e_free_blob:
+	kfree(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;
@@ -287,6 +352,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PDH_GEN:
 		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PDH_GEN, &input);
 		break;
+	case SEV_PEK_CSR:
+		ret = sev_ioctl_do_pek_csr(&input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;
-- 
2.9.5

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command
  2017-10-27 20:24   ` Borislav Petkov
@ 2017-10-30 11:49     ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30 11:49 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel



On 10/27/17 3:24 PM, Borislav Petkov wrote:
...
>> +
>>  static __exit void svm_hardware_unsetup(void)
>>  {
>>  	int cpu;
>>  
>> +	if (svm_sev_enabled())
>> +		sev_hardware_unsetup();
> Move that svm_sev_enabled() check into the function.

Sure, I will remove the check.

>
>> +
>>  	for_each_possible_cpu(cpu)
>>  		svm_cpu_uninit(cpu);
>>  
>> @@ -1361,6 +1389,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);
>> @@ -1443,6 +1474,28 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
>>  	return 0;
>>  }
>>  
>> +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;
> You're already checking !sev_guest() below - no need to do the
> svm_sev_enabled() check again.

Agreed, I will remove it.


>> +{
>> +	int pos;
>> +
>> +	if (!svm_sev_enabled())
>> +		return -EINVAL;
> You already checked that in svm_mem_enc_op() - no need to do it again.

Agreed, I will remove it
>
>> +	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_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
>> +{
>> +	struct kvm_sev_info *sev = &kvm->arch.sev_info;
>> +	int asid, ret;
>> +
>> +	ret = sev_platform_init(NULL, &argp->error);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = -EBUSY;
>> +	asid = sev_asid_new();
> This operation is cheaper so do it first and then sev_platform_init()
> so that in case sev_asid_new() fails, you don't "toggle" the PSP
> unnecessarily.

Sure, I will change the order.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  2017-10-27 20:25   ` Borislav Petkov
@ 2017-10-30 13:56     ` Brijesh Singh
  2017-10-30 15:12       ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30 13:56 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel



On 10/27/17 3:25 PM, Borislav Petkov wrote:

...

>> +				ret = -EFAULT;
>> +		} else {
>> +			memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
> arch/x86/kvm/svm.c: In function ‘svm_mem_enc_op’:
> arch/x86/kvm/svm.c:6115:4: warning: argument 1 null where non-null expected [-Wnonnull]
>     memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from ./arch/x86/include/asm/string.h:4:0,
>                  from ./include/linux/string.h:18,
>                  from ./include/linux/bitmap.h:8,
>                  from ./include/linux/cpumask.h:11,
>                  from ./arch/x86/include/asm/cpumask.h:4,
>                  from ./arch/x86/include/asm/msr.h:10,
>                  from ./arch/x86/include/asm/processor.h:20,
>                  from ./arch/x86/include/asm/cpufeature.h:4,
>                  from ./arch/x86/include/asm/thread_info.h:52,
>                  from ./include/linux/thread_info.h:37,
>                  from ./arch/x86/include/asm/preempt.h:6,
>                  from ./include/linux/preempt.h:80,
>                  from ./include/linux/hardirq.h:4,
>                  from ./include/linux/kvm_host.h:10,
>                  from arch/x86/kvm/svm.c:20:
> ./arch/x86/include/asm/string_64.h:31:14: note: in a call to function ‘memcpy’ declared here
>  extern void *memcpy(void *to, const void *from, size_t len);
>               ^~~~~~
>

I am not able to reproduce the build warning in my setup, what config
option or compiler you are using to  trigger this issue ?  I am on
Fedora with gcc 6.4.x. Logically, the code looks okay. I can try to
rearrange code to fix the warning. I have not touched this function
since couple of rev, have u seen similar warning in previous versions
(v5, v4 etc). thanks

-Brijesh
 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  2017-10-30 13:56     ` Brijesh Singh
@ 2017-10-30 15:12       ` Borislav Petkov
  2017-10-30 16:33         ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-30 15:12 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
	Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel

On Mon, Oct 30, 2017 at 08:56:13AM -0500, Brijesh Singh wrote:
> I am not able to reproduce the build warning in my setup, what config
> option or compiler you are using to  trigger this issue ?

gcc7 has gotten smarter.

> I am on Fedora with gcc 6.4.x. Logically, the code looks okay. I can
> try to rearrange code to fix the warning. I have not touched this
> function since couple of rev, have u seen similar warning in previous
> versions (v5, v4 etc). thanks

Lemme see:

sev_dbg_crypt() does

                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);

and that 4th argument is 0. IINM, that's dst_kaddr and you're doing

	memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
		^^^^^^^^^^^^^^^^

BOOM!

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
  2017-10-30 15:12       ` Borislav Petkov
@ 2017-10-30 16:33         ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30 16:33 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: brijesh.singh, kvm, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Paolo Bonzini, Radim Krčmář,
	Joerg Roedel, Tom Lendacky, x86, linux-kernel



On 10/30/17 10:12 AM, Borislav Petkov wrote:
...
> Lemme see:
>
> sev_dbg_crypt() does
>
>                 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);
>
> and that 4th argument is 0. IINM, that's dst_kaddr and you're doing
>
> 	memcpy((void *)dst_kaddr, page_address(tpage) + offset, size);
> 		^^^^^^^^^^^^^^^^

The 3rd argument 'dst_uaddr' should always contain a valid value and 4th
argument should not be used. The else statement should not be used
during DBG_DECRYPT command.

                 /*
                  * 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);
                 }


Here is sequence

sev_dbg_crypt() does:

      dst_vaddr = params.dst_uaddr;
      .......
      for(...) {
            dst_p = sev_pin_memory(..., dst_vaddr ...)
            if (!dst_p) {
                    return -EFAULT;
             }

           

	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);

....


The 3rd argument will be zero when we are handling the  DBG_ENCRYPT 
with length not aligned to 16-byte boundary.  In that case we allocate a
intermediate buffer (dst_kaddr). I will try with gcc7 and  look into
restructure code to fix the compiler warning.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-29 20:48   ` [Part2 PATCH v6.1 16/38] " Brijesh Singh
  2017-10-29 21:14     ` Brijesh Singh
@ 2017-10-30 17:21     ` Borislav Petkov
  2017-10-30 17:49       ` Brijesh Singh
  1 sibling, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-30 17:21 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On Sun, Oct 29, 2017 at 03:48:25PM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the 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:

...

> Changes since v6:
>  * Add functions to init and shutdown firmware during modprobe
>  * Add sev_state variable in psp_device to keep track of the INIT and SHUTDOWN
>    state
>  * Don't allow caller to shutdown the FW because SHUTDOWN will be done during
>    the module removal.
>  * Drop the fw_init_mutex and init_refcount because we no longer allow apps to
>    INIT and UINIT the platform

Yes, it definitely looks much better this way. Thanks for doing that!

> 
>  drivers/crypto/ccp/psp-dev.c | 360 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/crypto/ccp/psp-dev.h |  22 +++
>  drivers/crypto/ccp/sp-dev.c  |   9 ++
>  drivers/crypto/ccp/sp-dev.h  |   4 +
>  include/linux/psp-sev.h      | 158 +++++++++++++++++++
>  5 files changed, 553 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index b5789f878560..060f57ac08b3 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -26,6 +26,15 @@
>  #include "sp-dev.h"
>  #include "psp-dev.h"
>  
> +#define DEVICE_NAME	"sev"
> +
> +static DEFINE_MUTEX(sev_cmd_mutex);
> +static struct sev_misc_dev *misc_dev;
> +static struct psp_device *psp_master;
> +
> +static int sev_platform_shutdown_locked(int *error);
> +static int sev_platform_init_locked(struct sev_data_init *data, int *error);

Useless forward declarations.

>  static struct psp_device *psp_alloc_struct(struct sp_device *sp)
>  {
>  	struct device *dev = sp->dev;

...

> +static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)

You can use the "__" prefix to denote that it is a lower-level helper:

__sev_do_cmd
__sev_do_cmd_locked

Ditto for the other locked functions.

> +	struct psp_device *psp = psp_master;
> +	unsigned int phys_lsb, phys_msb;
> +	unsigned int reg, ret = 0;
> +
> +	if (!psp)
> +		return -ENODEV;
> +
> +	/* Get the physical address of the command buffer */
> +	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);
> +
> +	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 |= PSP_CMDRESP_IOC;
> +	iowrite32(reg, psp->io_regs + PSP_CMDRESP);
> +
> +	/* wait for command completion */
> +	sev_wait_cmd_ioc(psp, &reg);
> +
> +	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;
> +	}
> +
> +	print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> +			     sev_cmd_buffer_len(cmd), false);
> +
> +	return ret;
> +}

...

> +static int sev_platform_init_locked(struct sev_data_init *data, int *error)
> +{
> +	struct psp_device *psp = psp_master;
> +	struct sev_data_init *input = NULL;
> +	int rc = 0;
> +
> +	if (!psp)
> +		return -ENODEV;
> +
> +	if (psp->sev_state == SEV_STATE_INIT)
> +		return 0;
> +
> +	if (!data) {
> +		input = kzalloc(sizeof(*input), GFP_KERNEL);
> +		if (!input)
> +			return -ENOMEM;
> +
> +		data = input;
> +	}

You can do the allocation in the enclosing function, outside of the
critical region so that you can keep it shorter.

Or even better: if you're going to synchronize the commands with a
mutex, you can define a static struct sev_data_init input in this file
which you always hand in and then you can save yourself the kmalloc
calls.

> +
> +	rc = sev_do_cmd_locked(SEV_CMD_INIT, data, error);
> +	if (rc)
> +		goto e_free;
> +
> +	psp->sev_state = SEV_STATE_INIT;
> +	dev_dbg(psp->dev, "SEV firmware intialized\n");

WARNING: 'intialized' may be misspelled - perhaps 'initialized'?
#254: FILE: drivers/crypto/ccp/psp-dev.c:215:
+       dev_dbg(psp->dev, "SEV firmware intialized\n");

WARNING: space prohibited between function name and open parenthesis '('
#445: FILE: drivers/crypto/ccp/psp-dev.c:440:
+       data = kzalloc(sizeof (*data), GFP_KERNEL);

Ok, tell me: how many times do I have to write:

"Please integrate scripts/checkpatch.pl into your patch creation
workflow. Some of the warnings/errors *actually* make sense."

until you actually do it?

> +
> +e_free:
> +	kfree(input);
> +	return rc;
> +}
> +
> +int sev_platform_init(struct sev_data_init *data, int *error)
> +{
> +	int rc;
> +
> +	mutex_lock(&sev_cmd_mutex);
> +	rc = sev_platform_init_locked(data, error);
> +	mutex_unlock(&sev_cmd_mutex);
> +
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(sev_platform_init);
> +
> +static int sev_platform_shutdown_locked(int *error)
> +{
> +	int ret;
> +
> +	ret = sev_do_cmd_locked(SEV_CMD_SHUTDOWN, 0, error);
> +	if (ret)
> +		return ret;
> +
> +	psp_master->sev_state = SEV_STATE_UNINIT;
> +	dev_dbg(psp_master->dev, "SEV firmware shutdown\n");
> +
> +	return ret;
> +}
> +
> +int sev_platform_shutdown(int *error)
> +{
> +	if (error)
> +		*error = 0;
> +
> +	return 0;
> +}

I'm guessing that that's just bare-bones and it will get filled up in
the next patches. Otherwise it looks pretty useless.

If it is just to block the user from sending SHUTDOWN to the PSP
master, just do that in the ioctl directly - no need to call some empty
functions.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-30 17:21     ` Borislav Petkov
@ 2017-10-30 17:49       ` Brijesh Singh
  2017-10-30 17:57         ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-30 17:49 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 10/30/2017 12:21 PM, Borislav Petkov wrote:
...

> 
> Useless forward declarations.
> 

Actually its helpful in other patches. I was trying to avoid making too 
many code movement in other patches to eliminate the forward 
declarations. I guess I can fix in v7.


>>   static struct psp_device *psp_alloc_struct(struct sp_device *sp)
>>   {
>>   	struct device *dev = sp->dev;
> 
> ...
> 
>> +static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
> 
> You can use the "__" prefix to denote that it is a lower-level helper:
> 
> __sev_do_cmd
> __sev_do_cmd_locked
> 
> Ditto for the other locked functions.

noted

> ...
> 
>> +static int sev_platform_init_locked(struct sev_data_init *data, int *error)
>> +{
>> +	struct psp_device *psp = psp_master;
>> +	struct sev_data_init *input = NULL;
>> +	int rc = 0;
>> +
>> +	if (!psp)
>> +		return -ENODEV;
>> +
>> +	if (psp->sev_state == SEV_STATE_INIT)
>> +		return 0;
>> +
>> +	if (!data) {
>> +		input = kzalloc(sizeof(*input), GFP_KERNEL);
>> +		if (!input)
>> +			return -ENOMEM;
>> +
>> +		data = input;
>> +	}
> 
> You can do the allocation in the enclosing function, outside of the
> critical region so that you can keep it shorter.
> 
> Or even better: if you're going to synchronize the commands with a
> mutex, you can define a static struct sev_data_init input in this file
> which you always hand in and then you can save yourself the kmalloc
> calls.
> 

If the buffer is allocated on the stack then there is no guarantee that 
__pa() will gives us a valid physical address. IIRC, when 
CONFIG_VMAP_STACK=y then stack space is mapped similar to vmalloc'd 
storage and __pa() will not work.

Since we need to pass the physical address to PSP hence variable 
allocated on the stack will not work.

I can certainly move the allocation outside, but then it may increase 
the code size in other functions. If its not a big deal then I would 
prefer to keep what we have.


...
>> +
>> +int sev_platform_shutdown(int *error)
>> +{
>> +	if (error)
>> +		*error = 0;
>> +
>> +	return 0;
>> +}
> 
> I'm guessing that that's just bare-bones and it will get filled up in
> the next patches. Otherwise it looks pretty useless.
> 

Well, we are not expanding in other patches. I was also debating on what 
to do with this function. Since we need sev_platform_init() hence it 
made sense to add sev_platform_shutdown() as well. If we add the 
function then I wanted to make sure that we set the *error = SUCCESS so 
that caller knows that function succeeded.


> If it is just to block the user from sending SHUTDOWN to the PSP
> master, just do that in the ioctl directly - no need to call some empty
> functions.
> 

The function is not used by userspace ioctl, its used by kvm drv when it 
launch/terminates the SEV guest.

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-30 17:49       ` Brijesh Singh
@ 2017-10-30 17:57         ` Borislav Petkov
  2017-10-31  1:29           ` Brijesh Singh
  0 siblings, 1 reply; 120+ messages in thread
From: Borislav Petkov @ 2017-10-30 17:57 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On Mon, Oct 30, 2017 at 12:49:14PM -0500, Brijesh Singh wrote:
> If the buffer is allocated on the stack then there is no guarantee that

static global is not allocated on the stack.

> I can certainly move the allocation outside, but then it may increase the
> code size in other functions. If its not a big deal then I would prefer to
> keep what we have.

Avoiding repeated k*alloc calls is always a good thing. Actually kmalloc-ing 20
bytes each time sounds like it is not worth the calling overhead to me.

> The function is not used by userspace ioctl, its used by kvm drv when it
> launch/terminates the SEV guest.

Just do that directly in the ioctl instead of having a dumb function.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-30 17:57         ` Borislav Petkov
@ 2017-10-31  1:29           ` Brijesh Singh
  2017-10-31 10:39             ` Borislav Petkov
  0 siblings, 1 reply; 120+ messages in thread
From: Brijesh Singh @ 2017-10-31  1:29 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 10/30/17 12:57 PM, Borislav Petkov wrote:
> On Mon, Oct 30, 2017 at 12:49:14PM -0500, Brijesh Singh wrote:
>> If the buffer is allocated on the stack then there is no guarantee that
> static global is not allocated on the stack.

Okay, Just tried static global with CONFIG_VMAP_STACK=y and I am getting
wrong physical address with __pa. PSP command fails with error code
"INVALID_ADDRESS". The same thing works fine with kmalloc() buffer.

>> I can certainly move the allocation outside, but then it may increase the
>> code size in other functions. If its not a big deal then I would prefer to
>> keep what we have.
> Avoiding repeated k*alloc calls is always a good thing. Actually kmalloc-ing 20
> bytes each time sounds like it is not worth the calling overhead to me.
>

To avoid repeated k*alloc calls, I could devm_kzalloc() these variable 
during sev_init() and reuse them when needed.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
  2017-10-31  1:29           ` Brijesh Singh
@ 2017-10-31 10:39             ` Borislav Petkov
  0 siblings, 0 replies; 120+ messages in thread
From: Borislav Petkov @ 2017-10-31 10:39 UTC (permalink / raw)
  To: Brijesh Singh
  Cc: Paolo Bonzini, Radim Krčmář,
	Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
	linux-kernel

On Mon, Oct 30, 2017 at 08:29:25PM -0500, Brijesh Singh wrote:
> Okay, Just tried static global with CONFIG_VMAP_STACK=y and I am getting
> wrong physical address with __pa. PSP command fails with error code
> "INVALID_ADDRESS". The same thing works fine with kmalloc() buffer.

Ah, right, module space is vmalloc-ed.

> To avoid repeated k*alloc calls, I could devm_kzalloc() these variable 
> during sev_init() and reuse them when needed.

Yap, something like that.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD)
  2017-10-24 12:14 ` [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
@ 2017-11-02 20:18   ` Brijesh Singh
  0 siblings, 0 replies; 120+ messages in thread
From: Brijesh Singh @ 2017-11-02 20:18 UTC (permalink / raw)
  To: Herbert Xu, Paolo Bonzini
  Cc: brijesh.singh, kvm list, linux-crypto, Borislav Petkov, Lendacky,
	Thomas, Gary Hook

Hi Herbert,


On 10/24/2017 07:14 AM, Brijesh Singh wrote:
> Hi Herbert and Paolo,
> 
> 

....

> 
> Since the PSP patches touches both the CCP and KVM driver, hence I was
> wondering if you guys have any thought on how PSP patches will be
> merged? I am talking about Patch 9 to 20 from this series. I have
> ensured that patches apply cleanly on both kvm/master and
> cryptodev-2.6/master. We can do this in one of two ways:
> 
> - Paolo can merge the PSP support through the KVM branch
> 
> or
> 
> - Herbert can create a topic branch with PSP changes and Paolo can use
> that topic branch.
> 
> Any visibility will help my next submission. thank you.
> 

Just checking, any thought on this?

Are you okay if the PSP changes are merged through the KVM tree?

-Brijesh

^ permalink raw reply	[flat|nested] 120+ messages in thread

end of thread, other threads:[~2017-11-02 20:19 UTC | newest]

Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-20  2:33 [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 01/38] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2017-10-20 13:18   ` Jonathan Corbet
2017-10-23 22:40     ` Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 02/38] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 03/38] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 04/38] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 05/38] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 06/38] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 07/38] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 08/38] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REG_REGION ioctl Brijesh Singh
2017-10-20 15:00   ` Borislav Petkov
2017-10-20  2:33 ` [Part2 PATCH v6 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
2017-10-24 18:40   ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 10/38] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
2017-10-24 18:40   ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 11/38] crypto: ccp: Define SEV key management " Brijesh Singh
2017-10-24 18:40   ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-10-24 18:40   ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
2017-10-23  7:34   ` Borislav Petkov
2017-10-23  7:34     ` Borislav Petkov
2017-10-23 20:05     ` Brijesh Singh
2017-10-23  9:20   ` Borislav Petkov
2017-10-23  9:20     ` Borislav Petkov
2017-10-23 19:57     ` Brijesh Singh
2017-10-26 13:56       ` Borislav Petkov
2017-10-26 16:56         ` Brijesh Singh
2017-10-26 17:44           ` Borislav Petkov
2017-10-26 17:44             ` Borislav Petkov
2017-10-26 19:26             ` Brijesh Singh
2017-10-26 20:13               ` Borislav Petkov
2017-10-26 20:59                 ` Brijesh Singh
2017-10-27  7:56                   ` Borislav Petkov
2017-10-27  7:56                     ` Borislav Petkov
2017-10-27 11:28                     ` Brijesh Singh
2017-10-27 20:15                       ` Borislav Petkov
2017-10-27 20:15                         ` Borislav Petkov
2017-10-27 20:25                         ` Brijesh Singh
2017-10-27 20:27                           ` Borislav Petkov
2017-10-27 21:28                             ` Brijesh Singh
2017-10-27 21:49                               ` Borislav Petkov
2017-10-27 22:59                                 ` Brijesh Singh
2017-10-28  0:00                                   ` Borislav Petkov
2017-10-28 12:20                                     ` Brijesh Singh
2017-10-29 20:48   ` [Part2 PATCH v6.1 16/38] " Brijesh Singh
2017-10-29 21:14     ` Brijesh Singh
2017-10-30 17:21     ` Borislav Petkov
2017-10-30 17:49       ` Brijesh Singh
2017-10-30 17:57         ` Borislav Petkov
2017-10-31  1:29           ` Brijesh Singh
2017-10-31 10:39             ` Borislav Petkov
2017-10-20  2:33 ` [Part2 PATCH v6 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
2017-10-23  7:42   ` Borislav Petkov
2017-10-23  7:42     ` Borislav Petkov
2017-10-24 18:41   ` Gary R Hook
2017-10-29 21:16   ` [Part2 PATCH v6.1 " Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
2017-10-23  8:48   ` Borislav Petkov
2017-10-24 18:41   ` Gary R Hook
2017-10-30  3:13   ` [Part2 PATCH v6.1 15/38] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 16/38] " Brijesh Singh
2017-10-23  9:32   ` Borislav Petkov
2017-10-23 12:15     ` Brijesh Singh
2017-10-23 12:32       ` Borislav Petkov
2017-10-23 13:32         ` Brijesh Singh
2017-10-23 14:10           ` Borislav Petkov
2017-10-23 20:00             ` Brijesh Singh
2017-10-23 21:55   ` [Part2 PATCH v6.1 " Brijesh Singh
2017-10-24 18:42     ` Gary R Hook
2017-10-26 14:22     ` Borislav Petkov
2017-10-20  2:33 ` [Part2 PATCH v6 17/38] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
2017-10-23 12:35   ` Borislav Petkov
2017-10-24 18:41   ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 18/38] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
2017-10-23 12:49   ` Borislav Petkov
2017-10-23 12:49     ` Borislav Petkov
2017-10-23 22:10   ` [Part2 PATCH v6.1 " Brijesh Singh
2017-10-24 18:42     ` Gary R Hook
2017-10-30  3:23     ` [Part2 PATCH v6.2 " Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
2017-10-23 22:14   ` [Part2 PATCH v6.1 " Brijesh Singh
2017-10-24 18:42     ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
2017-10-23 22:19   ` [Part2 PATCH v6.1 " Brijesh Singh
2017-10-24 18:43     ` Gary R Hook
2017-10-20  2:33 ` [Part2 PATCH v6 21/38] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 22/38] KVM: SVM: Add sev module_param Brijesh Singh
2017-10-20  2:33 ` [Part2 PATCH v6 23/38] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
2017-10-27 20:23   ` Borislav Petkov
2017-10-20  2:33 ` [Part2 PATCH v6 24/38] KVM: Define SEV key management command id Brijesh Singh
2017-10-27 20:23   ` Borislav Petkov
2017-10-20  2:34 ` [Part2 PATCH v6 25/38] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
2017-10-27 20:24   ` Borislav Petkov
2017-10-30 11:49     ` Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 26/38] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 27/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 28/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
2017-10-27 20:24   ` Borislav Petkov
2017-10-20  2:34 ` [Part2 PATCH v6 29/38] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
2017-10-27 20:24   ` Borislav Petkov
2017-10-20  2:34 ` [Part2 PATCH v6 30/38] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
2017-10-27 20:25   ` Borislav Petkov
2017-10-20  2:34 ` [Part2 PATCH v6 31/38] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
2017-10-27 20:25   ` Borislav Petkov
2017-10-20  2:34 ` [Part2 PATCH v6 32/38] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
2017-10-27 20:25   ` Borislav Petkov
2017-10-30 13:56     ` Brijesh Singh
2017-10-30 15:12       ` Borislav Petkov
2017-10-30 16:33         ` Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 33/38] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 34/38] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 35/38] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 36/38] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 37/38] KVM: SVM: Do not install #UD intercept when SEV is enabled Brijesh Singh
2017-10-20  2:34 ` [Part2 PATCH v6 38/38] KVM: X86: Restart the guest when insn_len is zero and " Brijesh Singh
2017-10-23 22:07 ` [Part2 PATCH v6.1 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command Brijesh Singh
2017-10-24 12:14 ` [Part2 PATCH v6 00/38] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-11-02 20:18   ` Brijesh Singh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.