* [Part2 PATCH v5 01/31] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 02/31] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
` (27 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Jonathan Corbet, Borislav Petkov, Tom Lendacky
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] 112+ messages in thread* [Part2 PATCH v5 02/31] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 01/31] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 03/31] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
` (26 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Borislav Petkov, 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] 112+ messages in thread* [Part2 PATCH v5 03/31] kvm: svm: prepare for new bit definition in nested_ctl
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 01/31] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 02/31] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 04/31] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
` (25 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, 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] 112+ messages in thread* [Part2 PATCH v5 04/31] kvm: svm: Add SEV feature definitions to KVM
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (2 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 03/31] kvm: svm: prepare for new bit definition in nested_ctl Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 05/31] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
` (24 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Tom Lendacky, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, 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] 112+ messages in thread* [Part2 PATCH v5 05/31] KVM: SVM: Prepare to reserve asid for SEV guest
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (3 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 04/31] kvm: svm: Add SEV feature definitions to KVM Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 14:33 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 06/31] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
` (23 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
In current implementation, asid allocation starts from 1, adds a
min_asid variable in svm_vcpu structure to allow starting asid from
something other than 1.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8186b8d7c469..2c3a3c88596c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -525,6 +525,7 @@ struct svm_cpu_data {
u64 asid_generation;
u32 max_asid;
u32 next_asid;
+ u32 min_asid;
struct kvm_ldttss_desc *tss_desc;
struct page *save_area;
@@ -782,6 +783,7 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
+ sd->min_asid = 1;
gdt = get_current_gdt_rw();
sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
@@ -2091,7 +2093,7 @@ static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
{
if (sd->next_asid > sd->max_asid) {
++sd->asid_generation;
- sd->next_asid = 1;
+ sd->next_asid = sd->min_asid;
svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 05/31] KVM: SVM: Prepare to reserve asid for SEV guest
2017-10-04 13:13 ` [Part2 PATCH v5 05/31] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
@ 2017-10-04 14:33 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-04 14:33 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:46AM -0500, Brijesh Singh wrote:
> In current implementation, asid allocation starts from 1, adds a
> min_asid variable in svm_vcpu structure to allow starting asid from
> something other than 1.
Rewrite that to:
"Currently, ASID allocation starts at 1. Add a svm_cpu_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
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> arch/x86/kvm/svm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Otherwise:
Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 06/31] KVM: X86: Extend CPUID range to include new leaf
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (4 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 05/31] KVM: SVM: Prepare to reserve asid for SEV guest Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 07/31] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
` (22 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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] 112+ messages in thread* [Part2 PATCH v5 07/31] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (5 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 06/31] KVM: X86: Extend CPUID range to include new leaf Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 14:50 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl Brijesh Singh
` (21 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_OP ioctl can
be used by qemu to issue a platform specific memory encryption commands.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virtual/kvm/api.txt | 16 ++++++++++++++++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 12 ++++++++++++
include/uapi/linux/kvm.h | 2 ++
4 files changed, 32 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e63a35fafef0..cc1aa76ee6cd 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: a opaque platform specific structure (in/out)
+Returns: 0 on success; -1 on error
+
+If platform supports creating encrypted VMs then this ioctl can be used for
+issuing a platform specific memory encryption commands to manage the encrypted
+VMs.
+
+Currently, this ioctl is used for issuing Secure Encrypted Virtualization (SEV)
+commands on AMD Processors. 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..a68e8ca78dd8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4010,6 +4010,14 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
return r;
}
+static int kvm_vm_ioctl_mem_enc_op(struct kvm *kvm, void __user *argp)
+{
+ if (kvm_x86_ops->mem_enc_op)
+ return kvm_x86_ops->mem_enc_op(kvm, argp);
+
+ return -ENOTTY;
+}
+
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -4270,6 +4278,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_enable_cap(kvm, &cap);
break;
}
+ case KVM_MEMORY_ENCRYPT_OP: {
+ r = kvm_vm_ioctl_mem_enc_op(kvm, argp);
+ break;
+ }
default:
r = -ENOTTY;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 838887587411..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] 112+ messages in thread* Re: [Part2 PATCH v5 07/31] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl
2017-10-04 13:13 ` [Part2 PATCH v5 07/31] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
@ 2017-10-04 14:50 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-04 14:50 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:48AM -0500, Brijesh Singh wrote:
> If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_OP ioctl can
> be used by qemu to issue a platform specific memory encryption commands.
Minor issues:
"If the hardware supports memory encryption then the
KVM_MEMORY_ENCRYPT_OP ioctl can be used by qemu to issue 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>
> ---
> Documentation/virtual/kvm/api.txt | 16 ++++++++++++++++
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/x86.c | 12 ++++++++++++
> include/uapi/linux/kvm.h | 2 ++
> 4 files changed, 32 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index e63a35fafef0..cc1aa76ee6cd 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: a opaque platform specific structure (in/out)
^
s/a/an/
> +Returns: 0 on success; -1 on error
> +
> +If platform supports creating encrypted VMs then this ioctl can be used for
"If the platform... "
> +issuing a platform specific memory encryption commands to manage the encrypted
change that line to:
"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.
> +
Nice.
With those addressed:
Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (6 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 07/31] KVM: Introduce KVM_MEMORY_ENCRYPT_OP ioctl Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 15:19 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
` (20 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REGISTER_REGION
and KVM_MEMORY_ENCRYPT_UNREGISTER_REGION ioctl's can be used by userspace to
register/unregister the guest memory regions which may contain the encrypted
data (e.g guest RAM, PCI BAR, SMRAM etc).
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Documentation/virtual/kvm/api.txt | 34 ++++++++++++++++++++++++++++++++++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 36 ++++++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 10 ++++++++++
4 files changed, 82 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index cc1aa76ee6cd..b007998c1403 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_REGISTER_REGION
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: struct kvm_enc_region (in)
+Returns: 0 on success; -1 on error
+
+This ioctl can be used to register the guest memory region which may contain
+the encrypted data (e.g guest RAM, SMRAM etc).
+
+The ioctl is used in the SEV-enabled guest. When encryption is enabled, the
+guest memory region may contain the encrypted data. 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. So relocating
+(or migrating) physical backing pages for the SEV guest will require some
+additional steps.
+
+Note: 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_UNREGISTER_REGION
+
+Capability: basic
+Architectures: x86
+Type: system
+Parameters: struct kvm_enc_region (in)
+Returns: 0 on success; -1 on error
+
+This ioctl can be used to unregister the guest memory region registered with
+KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl.
+
5. The kvm_run structure
------------------------
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 48001ca48c14..20fba8bfa727 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1063,6 +1063,8 @@ struct kvm_x86_ops {
void (*setup_mce)(struct kvm_vcpu *vcpu);
int (*mem_enc_op)(struct kvm *kvm, void __user *argp);
+ int (*mem_enc_register_region)(struct kvm *kvm, struct kvm_enc_region *argp);
+ int (*mem_enc_unregister_region)(struct kvm *kvm, struct kvm_enc_region *argp);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a68e8ca78dd8..95a95f24bcd7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4018,6 +4018,24 @@ static int kvm_vm_ioctl_mem_enc_op(struct kvm *kvm, void __user *argp)
return -ENOTTY;
}
+static int kvm_vm_ioctl_mem_enc_register_region(struct kvm *kvm,
+ struct kvm_enc_region *region)
+{
+ if (kvm_x86_ops->mem_enc_register_region)
+ return kvm_x86_ops->mem_enc_register_region(kvm, region);
+
+ return -ENOTTY;
+}
+
+static int kvm_vm_ioctl_mem_enc_unregister_region(struct kvm *kvm,
+ struct kvm_enc_region *region)
+{
+ if (kvm_x86_ops->mem_enc_unregister_region)
+ return kvm_x86_ops->mem_enc_unregister_region(kvm, region);
+
+ return -ENOTTY;
+}
+
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -4282,6 +4300,24 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_mem_enc_op(kvm, argp);
break;
}
+ case KVM_MEMORY_ENCRYPT_REGISTER_REGION: {
+ struct kvm_enc_region region;
+
+ r = -EFAULT;
+ if (copy_from_user(®ion, argp, sizeof(region)))
+ goto out;
+ r = kvm_vm_ioctl_mem_enc_register_region(kvm, ®ion);
+ break;
+ }
+ case KVM_MEMORY_ENCRYPT_UNREGISTER_REGION: {
+ struct kvm_enc_region region;
+
+ r = -EFAULT;
+ if (copy_from_user(®ion, argp, sizeof(region)))
+ goto out;
+ r = kvm_vm_ioctl_mem_enc_unregister_region(kvm, ®ion);
+ break;
+ }
default:
r = -ENOTTY;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 4a39d99c5f99..d595d3970390 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1359,6 +1359,16 @@ 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_REGISTER_REGION _IOR(KVMIO, 0xbb,\
+ struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREGISTER_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] 112+ messages in thread* Re: [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl
2017-10-04 13:13 ` [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl Brijesh Singh
@ 2017-10-04 15:19 ` Borislav Petkov
2017-10-04 17:18 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-04 15:19 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
Add the unreg ioctl to the patch subject:
Subject: [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_{UN,}REGISTER_REGION ioctls
On Wed, Oct 04, 2017 at 08:13:49AM -0500, Brijesh Singh wrote:
> If hardware supports memory encryption then KVM_MEMORY_ENCRYPT_REGISTER_REGION
> and KVM_MEMORY_ENCRYPT_UNREGISTER_REGION ioctl's can be used by userspace to
> register/unregister the guest memory regions which may contain the encrypted
> data (e.g guest RAM, PCI BAR, SMRAM etc).
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: x86@kernel.org
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> Documentation/virtual/kvm/api.txt | 34 ++++++++++++++++++++++++++++++++++
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/x86.c | 36 ++++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 10 ++++++++++
> 4 files changed, 82 insertions(+)
...
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 4a39d99c5f99..d595d3970390 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1359,6 +1359,16 @@ 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_REGISTER_REGION _IOR(KVMIO, 0xbb,\
> + struct kvm_enc_region)
> +#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
> + struct kvm_enc_region)
Yuck, those are needlessly too long. They could be just as understandable if
they were called:
#define KVM_MEM_ENC_REG_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
#define KVM_MEM_ENC_UNREG_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
or so... I know, it'll need to change the qemu patches but it is more
compact this way, IMO, and you don't have to break the _IOR line.
Anyway, here are some cleanups ontop. For example, you don't really need
those trivial wrappers
kvm_vm_ioctl_mem_enc_register_region() and
kvm_vm_ioctl_mem_enc_unregister_region()
and can simply call the function pointers directly.
Also, you might wanna do that for kvm_vm_ioctl_mem_enc_op() too, in the
previous patch, which is just as trivial.
The rest is text streamlining.
---
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index a9f3c3abd279..fa4bc1d43c68 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3414,20 +3414,20 @@ Type: system
Parameters: struct kvm_enc_region (in)
Returns: 0 on success; -1 on error
-This ioctl can be used to register the guest memory region which may contain the
-encrypted data (e.g guest RAM, SMRAM etc).
+This ioctl can be used to register a guest memory region which may
+contain encrypted data (e.g. guest RAM, SMRAM etc).
-The ioctl is used in the SEV-enabled guest. When encryption is enabled, the
-guest memory region may contain the encrypted data. 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. So relocating
-(or migrating) physical backing pages for the SEV guest will require some
-additional steps.
+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: 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.
+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_UNREGISTER_REGION
@@ -3437,8 +3437,8 @@ 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_REGISTER_REGION ioctl.
+This ioctl can be used to unregister the guest memory region registered
+with KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl above.
5. The kvm_run structure
------------------------
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 95a95f24bcd7..96a4506f9b4d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4018,24 +4018,6 @@ static int kvm_vm_ioctl_mem_enc_op(struct kvm *kvm, void __user *argp)
return -ENOTTY;
}
-static int kvm_vm_ioctl_mem_enc_register_region(struct kvm *kvm,
- struct kvm_enc_region *region)
-{
- if (kvm_x86_ops->mem_enc_register_region)
- return kvm_x86_ops->mem_enc_register_region(kvm, region);
-
- return -ENOTTY;
-}
-
-static int kvm_vm_ioctl_mem_enc_unregister_region(struct kvm *kvm,
- struct kvm_enc_region *region)
-{
- if (kvm_x86_ops->mem_enc_unregister_region)
- return kvm_x86_ops->mem_enc_unregister_region(kvm, region);
-
- return -ENOTTY;
-}
-
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -4306,7 +4288,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(®ion, argp, sizeof(region)))
goto out;
- r = kvm_vm_ioctl_mem_enc_register_region(kvm, ®ion);
+
+ r = -ENOTTY;
+ if (kvm_x86_ops->mem_enc_register_region)
+ r = kvm_x86_ops->mem_enc_register_region(kvm, ®ion);
break;
}
case KVM_MEMORY_ENCRYPT_UNREGISTER_REGION: {
@@ -4315,7 +4300,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(®ion, argp, sizeof(region)))
goto out;
- r = kvm_vm_ioctl_mem_enc_unregister_region(kvm, ®ion);
+
+ r = -ENOTTY;
+ if (kvm_x86_ops->mem_enc_unregister_region)
+ r = kvm_x86_ops->mem_enc_unregister_region(kvm, ®ion);
break;
}
default:
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl
2017-10-04 15:19 ` Borislav Petkov
@ 2017-10-04 17:18 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 17:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Radim Krčmář,
Joerg Roedel, Tom Lendacky
On 10/04/2017 10:19 AM, Borislav Petkov wrote:
>> +};
>> +
>> +#define KVM_MEMORY_ENCRYPT_REGISTER_REGION _IOR(KVMIO, 0xbb,\
>> + struct kvm_enc_region)
>> +#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
>> + struct kvm_enc_region)
>
> Yuck, those are needlessly too long. They could be just as understandable if
> they were called:
>
> #define KVM_MEM_ENC_REG_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
> #define KVM_MEM_ENC_UNREG_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
>
> or so... I know, it'll need to change the qemu patches but it is more
> compact this way, IMO, and you don't have to break the _IOR line.
>
Thanks for the patch Boris, I will take care of removing the wrapper
from kvm_vm_ioctl_mem_enc_op(). As per shorting the name is concerned,
if am open to suggestion. lets see if Paolo or Radim have any comments
on naming. If not, then I will shorten the name in next rev.
-Brijesh
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (7 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 08/31] KVM: Introduce KVM_MEMORY_ENCRYPT_REGISTER_REGION ioctl Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-04 21:47 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
` (19 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: 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: <brijesh.singh@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
---
drivers/crypto/ccp/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 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] 112+ messages in thread* Re: [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-10-04 13:13 ` [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
@ 2017-10-04 21:47 ` Borislav Petkov
2017-10-04 23:06 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-04 21:47 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Tom Lendacky, Gary Hook, Herbert Xu,
David S. Miller, linux-crypto
On Wed, Oct 04, 2017 at 08:13:50AM -0500, 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: <brijesh.singh@amd.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
For the future, when you carry a patch from someone else, your SOB
should come after the author's. I.e.,
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
i.e., the first SOB is the author's and the second is yours which means,
you've handled the patch further on, like sending it upstream, for
example.
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
2017-10-04 21:47 ` Borislav Petkov
@ 2017-10-04 23:06 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 23:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Tom Lendacky, Gary Hook,
Herbert Xu, David S. Miller, linux-crypto
On 10/04/2017 04:47 PM, Borislav Petkov wrote:>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
> i.e., the first SOB is the author's and the second is yours which means,
> you've handled the patch further on, like sending it upstream, for
> example.
>
Noted, thanks
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (8 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-05 9:56 ` Borislav Petkov
2017-10-06 23:09 ` [Part2 PATCH v5.1 " Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id Brijesh Singh
` (18 subsequent siblings)
28 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
The Platform Security Processor (PSP) is part of AMD Secure Processor
(AMD-SP), PSP is a dedicated processor that provides the support for
key management commands in a Secure Encrypted Virtualization (SEV) mode,
along with software-based Trusted Execution Environment (TEE) to enable
the third-party trusted applications.
Note that the key management functionality provided by the SEV firmware
can be used outside the kvm-amd driver hence we don't do depends on
CONFIG_KVM_AMD.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/Kconfig | 11 +++++
drivers/crypto/ccp/Makefile | 1 +
drivers/crypto/ccp/psp-dev.c | 109 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 61 ++++++++++++++++++++++++
drivers/crypto/ccp/sp-dev.c | 26 +++++++++++
drivers/crypto/ccp/sp-dev.h | 26 ++++++++++-
drivers/crypto/ccp/sp-pci.c | 46 ++++++++++++++++++
7 files changed, 279 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..454c25d9f197 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 the support for the AMD Platform Security Processor (PSP).
+ The PSP is a dedicated processor that provides support for key
+ management commands in Secure Encrypted Virtualization (SEV) mode,
+ along with software-based Trusted Execution Environment (TEE) to
+ enable the third-party trusted applications.
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 57f8debfcfb3..008bae7e26ec 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -7,6 +7,7 @@ ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
ccp-dmaengine.o \
ccp-debugfs.o
ccp-$(CONFIG_PCI) += sp-pci.o
+ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o
obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
new file mode 100644
index 000000000000..7480d4316239
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -0,0 +1,109 @@
+/*
+ * AMD Platform Security Processor (PSP) interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/ccp.h>
+
+#include "sp-dev.h"
+#include "psp-dev.h"
+
+const struct psp_vdata psp_entry = {
+ .offset = 0x10500,
+};
+
+static struct psp_device *psp_alloc_struct(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+
+ psp = devm_kzalloc(dev, sizeof(*psp), GFP_KERNEL);
+ if (!psp)
+ return NULL;
+
+ psp->dev = dev;
+ psp->sp = sp;
+
+ snprintf(psp->name, sizeof(psp->name), "psp-%u", sp->ord);
+
+ return psp;
+}
+
+static irqreturn_t psp_irq_handler(int irq, void *data)
+{
+ return IRQ_HANDLED;
+}
+
+int psp_dev_init(struct sp_device *sp)
+{
+ struct device *dev = sp->dev;
+ struct psp_device *psp;
+ int ret;
+
+ ret = -ENOMEM;
+ psp = psp_alloc_struct(sp);
+ if (!psp)
+ goto e_err;
+
+ sp->psp_data = psp;
+
+ psp->vdata = (struct psp_vdata *)sp->dev_vdata->psp_vdata;
+ if (!psp->vdata) {
+ ret = -ENODEV;
+ dev_err(dev, "missing driver data\n");
+ goto e_err;
+ }
+
+ psp->io_regs = sp->io_map + psp->vdata->offset;
+
+ /* Disable and clear interrupts until ready */
+ iowrite32(0, psp->io_regs + PSP_P2CMSG_INTEN);
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ /* Request an irq */
+ ret = sp_request_psp_irq(psp->sp, psp_irq_handler, psp->name, psp);
+ if (ret) {
+ dev_err(dev, "psp: unable to allocate an IRQ\n");
+ goto e_err;
+ }
+
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
+ /* Enable interrupt */
+ iowrite32(-1, psp->io_regs + PSP_P2CMSG_INTEN);
+
+ return 0;
+
+e_err:
+ sp->psp_data = NULL;
+
+ dev_notice(dev, "psp initialization failed\n");
+
+ return ret;
+}
+
+void psp_dev_destroy(struct sp_device *sp)
+{
+ struct psp_device *psp = sp->psp_data;
+
+ sp_free_psp_irq(sp, psp);
+}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
new file mode 100644
index 000000000000..d53970ef5960
--- /dev/null
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -0,0 +1,61 @@
+/*
+ * AMD Platform Security Processor (PSP) interface driver
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh <brijesh.singh@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PSP_DEV_H__
+#define __PSP_DEV_H__
+
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/spinlock.h>
+#include <linux/mutex.h>
+#include <linux/list.h>
+#include <linux/wait.h>
+#include <linux/dmapool.h>
+#include <linux/hw_random.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/dmaengine.h>
+
+#include "sp-dev.h"
+
+#define PSP_P2CMSG_INTEN 0x0110
+#define PSP_P2CMSG_INTSTS 0x0114
+
+#define PSP_C2PMSG_ATTR_0 0x0118
+#define PSP_C2PMSG_ATTR_1 0x011c
+#define PSP_C2PMSG_ATTR_2 0x0120
+#define PSP_C2PMSG_ATTR_3 0x0124
+#define PSP_P2CMSG_ATTR_0 0x0128
+
+#define PSP_CMDRESP_CMD_SHIFT 16
+#define PSP_CMDRESP_IOC BIT(0)
+#define PSP_CMDRESP_RESP BIT(31)
+#define PSP_CMDRESP_ERR_MASK 0xffff
+
+#define MAX_PSP_NAME_LEN 16
+
+struct psp_device {
+ struct list_head entry;
+
+ struct psp_vdata *vdata;
+ char name[MAX_PSP_NAME_LEN];
+
+ struct device *dev;
+ struct sp_device *sp;
+
+ void __iomem *io_regs;
+};
+
+extern const struct psp_vdata psp_entry;
+
+#endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index bef387c8abfd..cf101c039c8f 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -198,6 +198,8 @@ int sp_init(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_init(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_init(sp);
return 0;
}
@@ -206,6 +208,9 @@ void sp_destroy(struct sp_device *sp)
if (sp->dev_vdata->ccp_vdata)
ccp_dev_destroy(sp);
+ if (sp->dev_vdata->psp_vdata)
+ psp_dev_destroy(sp);
+
sp_del_device(sp);
}
@@ -237,6 +242,27 @@ int sp_resume(struct sp_device *sp)
}
#endif
+struct sp_device *sp_get_psp_master_device(void)
+{
+ struct sp_device *i, *ret = NULL;
+ unsigned long flags;
+
+ write_lock_irqsave(&sp_unit_lock, flags);
+ if (list_empty(&sp_units))
+ goto unlock;
+
+ list_for_each_entry(i, &sp_units, entry) {
+ if (i->psp_data)
+ break;
+ }
+
+ if (i->get_psp_master_device)
+ ret = i->get_psp_master_device();
+unlock:
+ write_unlock_irqrestore(&sp_unit_lock, flags);
+ return ret;
+}
+
static int __init sp_mod_init(void)
{
#ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 5ab486ade1ad..761dba176168 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,19 @@ struct ccp_vdata {
const unsigned int offset;
const unsigned int rsamax;
};
+
+struct psp_vdata {
+ const unsigned int version;
+ const struct psp_actions *perform;
+ const unsigned int offset;
+};
+
/* Structure to hold SP device data */
struct sp_dev_vdata {
const unsigned int bar;
const struct ccp_vdata *ccp_vdata;
- void *psp_vdata;
+ const struct psp_vdata *psp_vdata;
};
struct sp_device {
@@ -68,6 +75,10 @@ struct sp_device {
/* DMA caching attribute support */
unsigned int axcache;
+ /* get and set master device */
+ struct sp_device*(*get_psp_master_device)(void);
+ void (*set_psp_master_device)(struct sp_device *);
+
bool irq_registered;
bool use_tasklet;
@@ -103,6 +114,7 @@ void sp_free_ccp_irq(struct sp_device *sp, void *data);
int sp_request_psp_irq(struct sp_device *sp, irq_handler_t handler,
const char *name, void *data);
void sp_free_psp_irq(struct sp_device *sp, void *data);
+struct sp_device *sp_get_psp_master_device(void);
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
@@ -130,4 +142,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
}
#endif /* CONFIG_CRYPTO_DEV_SP_CCP */
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+
+int psp_dev_init(struct sp_device *sp);
+void psp_dev_destroy(struct sp_device *sp);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_dev_destroy(struct sp_device *sp) { }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 9859aa683a28..20a0f3543cf4 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -25,6 +25,7 @@
#include <linux/ccp.h>
#include "ccp-dev.h"
+#include "psp-dev.h"
#define MSIX_VECTORS 2
@@ -32,6 +33,7 @@ struct sp_pci {
int msix_count;
struct msix_entry msix_entry[MSIX_VECTORS];
};
+static struct sp_device *sp_dev_master;
static int sp_get_msix_irqs(struct sp_device *sp)
{
@@ -108,6 +110,45 @@ static void sp_free_irqs(struct sp_device *sp)
sp->psp_irq = 0;
}
+static bool sp_pci_is_master(struct sp_device *sp)
+{
+ struct device *dev_cur, *dev_new;
+ struct pci_dev *pdev_cur, *pdev_new;
+
+ dev_new = sp->dev;
+ dev_cur = sp_dev_master->dev;
+
+ pdev_new = to_pci_dev(dev_new);
+ pdev_cur = to_pci_dev(dev_cur);
+
+ if (pdev_new->bus->number < pdev_cur->bus->number)
+ return true;
+
+ if (PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn))
+ return true;
+
+ if (PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn))
+ return true;
+
+ return false;
+}
+
+static void psp_set_master(struct sp_device *sp)
+{
+ if (!sp_dev_master) {
+ sp_dev_master = sp;
+ return;
+ }
+
+ if (sp_pci_is_master(sp))
+ sp_dev_master = sp;
+}
+
+static struct sp_device *psp_get_master(void)
+{
+ return sp_dev_master;
+}
+
static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct sp_device *sp;
@@ -166,6 +207,8 @@ static int sp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto e_err;
pci_set_master(pdev);
+ sp->set_psp_master_device = psp_set_master;
+ sp->get_psp_master_device = psp_get_master;
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48));
if (ret) {
@@ -237,6 +280,9 @@ static const struct sp_dev_vdata dev_vdata[] = {
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
.ccp_vdata = &ccpv5a,
#endif
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+ .psp_vdata = &psp_entry
+#endif
},
{
.bar = 2,
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-04 13:13 ` [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-10-05 9:56 ` Borislav Petkov
2017-10-06 23:09 ` [Part2 PATCH v5.1 " Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-05 9:56 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Wed, Oct 04, 2017 at 08:13:51AM -0500, Brijesh Singh wrote:
> The Platform Security Processor (PSP) is part of AMD Secure Processor
> (AMD-SP), PSP is a dedicated processor that provides the support for
> key management commands in a Secure Encrypted Virtualization (SEV) mode,
> along with software-based Trusted Execution Environment (TEE) to enable
> the third-party trusted applications.
>
> Note that the key management functionality provided by the SEV firmware
> can be used outside the kvm-amd driver hence we don't do depends on
> CONFIG_KVM_AMD.
Minor corrections:
"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."
...
> diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
> index 9c84f9838931..454c25d9f197 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 the support for the AMD Platform Security Processor (PSP).
> + The PSP is a dedicated processor that provides support for key
> + management commands in Secure Encrypted Virtualization (SEV) mode,
> + along with software-based Trusted Execution Environment (TEE) to
> + enable the third-party trusted applications.
Minor corrections:
---
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 454c25d9f197..b9dfae47aefd 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -39,8 +39,8 @@ config CRYPTO_DEV_SP_PSP
default y
depends on CRYPTO_DEV_CCP_DD && X86_64
help
- Provide the support for the AMD Platform Security Processor (PSP).
+ 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 the third-party trusted applications.
+ enable third-party trusted applications.
with that taken care of:
Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5.1 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support
2017-10-04 13:13 ` [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-10-05 9:56 ` Borislav Petkov
@ 2017-10-06 23:09 ` Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-06 23:09 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The Platform Security Processor (PSP) is part of 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>
---
Changes since v5:
* move psp_entry in sp-pci.c (based on Boris improvement patch)
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 | 26 ++++++++++-
drivers/crypto/ccp/sp-pci.c | 52 +++++++++++++++++++++
7 files changed, 279 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..761dba176168 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -42,12 +42,19 @@ struct ccp_vdata {
const unsigned int offset;
const unsigned int rsamax;
};
+
+struct psp_vdata {
+ const unsigned int version;
+ const struct psp_actions *perform;
+ const unsigned int offset;
+};
+
/* Structure to hold SP device data */
struct sp_dev_vdata {
const unsigned int bar;
const struct ccp_vdata *ccp_vdata;
- void *psp_vdata;
+ const struct psp_vdata *psp_vdata;
};
struct sp_device {
@@ -68,6 +75,10 @@ struct sp_device {
/* DMA caching attribute support */
unsigned int axcache;
+ /* get and set master device */
+ struct sp_device*(*get_psp_master_device)(void);
+ void (*set_psp_master_device)(struct sp_device *);
+
bool irq_registered;
bool use_tasklet;
@@ -103,6 +114,7 @@ void sp_free_ccp_irq(struct sp_device *sp, void *data);
int sp_request_psp_irq(struct sp_device *sp, irq_handler_t handler,
const char *name, void *data);
void sp_free_psp_irq(struct sp_device *sp, void *data);
+struct sp_device *sp_get_psp_master_device(void);
#ifdef CONFIG_CRYPTO_DEV_SP_CCP
@@ -130,4 +142,16 @@ static inline int ccp_dev_resume(struct sp_device *sp)
}
#endif /* CONFIG_CRYPTO_DEV_SP_CCP */
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+
+int psp_dev_init(struct sp_device *sp);
+void psp_dev_destroy(struct sp_device *sp);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int psp_dev_init(struct sp_device *sp) { return 0; }
+static inline void psp_dev_destroy(struct sp_device *sp) { }
+
+#endif /* CONFIG_CRYPTO_DEV_SP_PSP */
+
#endif
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 9859aa683a28..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] 112+ messages in thread
* [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (9 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 10/31] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-05 20:56 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
` (17 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
Define Secure Encrypted Virtualization (SEV) key management command id
and structure. The command definition is available in SEV KM [1] spec
0.14.
[1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/linux/psp-sev.h | 515 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 515 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..f01d0e3b09b8
--- /dev/null
+++ b/include/linux/psp-sev.h
@@ -0,0 +1,515 @@
+/*
+ * 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__
+
+#ifdef CONFIG_X86
+#include <linux/mem_encrypt.h>
+
+#define __psp_pa(x) __sme_pa(x)
+#else
+#define __psp_pa(x) __pa(x)
+#endif
+
+#define SEV_FW_BLOB_MAX_SIZE 0x4000 /* 16KB */
+
+/**
+ * SEV platform state
+ */
+enum sev_state {
+ SEV_STATE_UNINIT = 0x0,
+ SEV_STATE_INIT = 0x1,
+ SEV_STATE_WORKING = 0x2,
+
+ SEV_STATE_MAX
+};
+
+/**
+ * SEV platform and guest management commands
+ */
+enum sev_cmd {
+ /* platform commands */
+ SEV_CMD_INIT = 0x001,
+ SEV_CMD_SHUTDOWN = 0x002,
+ SEV_CMD_FACTORY_RESET = 0x003,
+ SEV_CMD_PLATFORM_STATUS = 0x004,
+ SEV_CMD_PEK_GEN = 0x005,
+ SEV_CMD_PEK_CSR = 0x006,
+ SEV_CMD_PEK_CERT_IMPORT = 0x007,
+ SEV_CMD_PDH_CERT_EXPORT = 0x008,
+ SEV_CMD_PDH_GEN = 0x009,
+ SEV_CMD_DF_FLUSH = 0x00A,
+
+ /* Guest commands */
+ SEV_CMD_DECOMMISSION = 0x020,
+ SEV_CMD_ACTIVATE = 0x021,
+ SEV_CMD_DEACTIVATE = 0x022,
+ SEV_CMD_GUEST_STATUS = 0x023,
+
+ /* Guest launch commands */
+ SEV_CMD_LAUNCH_START = 0x030,
+ SEV_CMD_LAUNCH_UPDATE_DATA = 0x031,
+ SEV_CMD_LAUNCH_UPDATE_VMSA = 0x032,
+ SEV_CMD_LAUNCH_MEASURE = 0x033,
+ SEV_CMD_LAUNCH_UPDATE_SECRET = 0x034,
+ SEV_CMD_LAUNCH_FINISH = 0x035,
+
+ /* Guest migration commands (outgoing) */
+ SEV_CMD_SEND_START = 0x040,
+ SEV_CMD_SEND_UPDATE_DATA = 0x041,
+ SEV_CMD_SEND_UPDATE_VMSA = 0x042,
+ SEV_CMD_SEND_FINISH = 0x043,
+
+ /* Guest migration commands (incoming) */
+ SEV_CMD_RECEIVE_START = 0x050,
+ SEV_CMD_RECEIVE_UPDATE_DATA = 0x051,
+ SEV_CMD_RECEIVE_UPDATE_VMSA = 0x052,
+ SEV_CMD_RECEIVE_FINISH = 0x053,
+
+ /* Guest debug commands */
+ SEV_CMD_DBG_DECRYPT = 0x060,
+ SEV_CMD_DBG_ENCRYPT = 0x061,
+
+ SEV_CMD_MAX,
+};
+
+/**
+ * status code returned by the commands
+ */
+enum psp_ret_code {
+ SEV_RET_SUCCESS = 0,
+ SEV_RET_INVALID_PLATFORM_STATE,
+ SEV_RET_INVALID_GUEST_STATE,
+ SEV_RET_INAVLID_CONFIG,
+ SEV_RET_INVALID_len,
+ SEV_RET_ALREADY_OWNED,
+ SEV_RET_INVALID_CERTIFICATE,
+ SEV_RET_POLICY_FAILURE,
+ SEV_RET_INACTIVE,
+ SEV_RET_INVALID_ADDRESS,
+ SEV_RET_BAD_SIGNATURE,
+ SEV_RET_BAD_MEASUREMENT,
+ SEV_RET_ASID_OWNED,
+ SEV_RET_INVALID_ASID,
+ SEV_RET_WBINVD_REQUIRED,
+ SEV_RET_DFFLUSH_REQUIRED,
+ SEV_RET_INVALID_GUEST,
+ SEV_RET_INVALID_COMMAND,
+ SEV_RET_ACTIVE,
+ SEV_RET_HWSEV_RET_PLATFORM,
+ SEV_RET_HWSEV_RET_UNSAFE,
+ SEV_RET_UNSUPPORTED,
+ SEV_RET_MAX,
+};
+
+/**
+ * struct sev_data_init - INIT command parameters
+ *
+ * @flags: processing flags
+ * @tmr_address: system physical address used for SEV-ES
+ * @tmr_len: len of tmr_address
+ */
+struct __attribute__((__packed__)) sev_data_init {
+ u32 flags; /* In */
+ u32 reserved; /* In */
+ u64 tmr_address; /* In */
+ u32 tmr_len; /* In */
+};
+
+/**
+ * struct sev_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct __attribute__((__packed__)) sev_data_status {
+ u8 api_major; /* Out */
+ u8 api_minor; /* Out */
+ u8 state; /* Out */
+ u8 owner : 1; /* Out */
+ u8 reserved1 : 7;
+ u32 config : 1; /* Out */
+ u32 reserved2 : 23;
+ u32 build : 8; /* Out */
+ u32 guest_count; /* Out */
+};
+
+/**
+ * struct sev_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @len: len of certificate
+ */
+struct __attribute__((__packed__)) sev_data_pek_csr {
+ u64 address; /* In */
+ u32 len; /* In/Out */
+};
+
+/**
+ * struct sev_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: len of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: len of OCA certificate
+ */
+struct __attribute__((__packed__)) sev_data_pek_cert_import {
+ u64 pek_cert_address; /* In */
+ u32 pek_cert_len; /* In */
+ u32 reserved; /* In */
+ u64 oca_cert_address; /* In */
+ u32 oca_cert_len; /* In */
+};
+
+/**
+ * struct sev_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: len of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: len of PDH certificate chain
+ */
+struct __attribute__((__packed__)) sev_data_pdh_cert_export {
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In/Out */
+ u32 reserved; /* In */
+ u64 cert_chain_address; /* In */
+ u32 cert_chain_len; /* In/Out */
+};
+
+/**
+ * struct sev_data_decommission - DECOMMISSION command parameters
+ *
+ * @handle: handle of the VM to decommission
+ */
+struct __attribute__((__packed__)) sev_data_decommission {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_activate - ACTIVATE command parameters
+ *
+ * @handle: handle of the VM to activate
+ * @asid: asid assigned to the VM
+ */
+struct __attribute__((__packed__)) sev_data_activate {
+ u32 handle; /* In */
+ u32 asid; /* In */
+};
+
+/**
+ * struct sev_data_deactivate - DEACTIVATE command parameters
+ *
+ * @handle: handle of the VM to deactivate
+ */
+struct __attribute__((__packed__)) sev_data_deactivate {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_guest_status - SEV GUEST_STATUS command parameters
+ *
+ * @handle: handle of the VM to retrieve status
+ * @policy: policy information for the VM
+ * @asid: current ASID of the VM
+ * @state: current state of the VM
+ */
+struct __attribute__((__packed__)) sev_data_guest_status {
+ u32 handle; /* In */
+ u32 policy; /* Out */
+ u32 asid; /* Out */
+ u8 state; /* Out */
+};
+
+/**
+ * struct sev_data_launch_start - LAUNCH_START command parameters
+ *
+ * @handle: handle assigned to the VM
+ * @policy: guest launch policy
+ * @dh_cert_address: physical address of DH certificate blob
+ * @dh_cert_len: len of DH certificate blob
+ * @session_address: physical address of session parameters
+ * @session_len: len of session parameters
+ */
+struct __attribute__((__packed__)) sev_data_launch_start {
+ u32 handle; /* In/Out */
+ u32 policy; /* In */
+ u64 dh_cert_address; /* In */
+ u32 dh_cert_len; /* In */
+ u32 reserved; /* In */
+ u64 session_address; /* In */
+ u32 session_len; /* In */
+};
+
+/**
+ * struct sev_data_launch_update_data - LAUNCH_UPDATE_DATA command parameter
+ *
+ * @handle: handle of the VM to update
+ * @len: len of memory to be encrypted
+ * @address: physical address of memory region to encrypt
+ */
+struct __attribute__((__packed__)) sev_data_launch_update_data {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In */
+};
+
+/**
+ * struct sev_data_launch_update_vmsa - LAUNCH_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM
+ * @address: physical address of memory region to encrypt
+ * @len: len of memory region to encrypt
+ */
+struct __attribute__((__packed__)) sev_data_launch_update_vmsa {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In */
+};
+
+/**
+ * struct sev_data_launch_measure - LAUNCH_MEASURE command parameters
+ *
+ * @handle: handle of the VM to process
+ * @address: physical address containing the measurement blob
+ * @len: len of measurement blob
+ */
+struct __attribute__((__packed__)) sev_data_launch_measure {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 address; /* In */
+ u32 len; /* In/Out */
+};
+
+/**
+ * struct sev_data_launch_secret - LAUNCH_SECRET command parameters
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing the packet header
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest_paddr
+ * @trans_address: physical address of transport memory buffer
+ * @trans_len: len of transport memory buffer
+ */
+struct __attribute__((__packed__)) sev_data_launch_secret {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_launch_finish - LAUNCH_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct __attribute__((__packed__)) sev_data_launch_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_send_start - SEND_START command parameters
+ *
+ * @handle: handle of the VM to process
+ * @policy: policy information for the VM
+ * @pdh_cert_address: physical address containing PDH certificate
+ * @pdh_cert_len: len of PDH certificate
+ * @plat_certs_address: physical address containing platform certificate
+ * @plat_certs_len: len of platform certificate
+ * @amd_certs_address: physical address containing AMD certificate
+ * @amd_certs_len: len of AMD certificate
+ * @session_address: physical address containing Session data
+ * @session_len: len of session data
+ */
+struct __attribute__((__packed__)) sev_data_send_start {
+ u32 handle; /* In */
+ u32 policy; /* Out */
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In */
+ u32 reserved1;
+ u64 plat_cert_address; /* In */
+ u32 plat_cert_len; /* In */
+ u32 reserved2;
+ u64 amd_cert_address; /* In */
+ u32 amd_cert_len; /* In */
+ u32 reserved3;
+ u64 session_address; /* In */
+ u32 session_len; /* In/Out */
+};
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_DATA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct __attribute__((__packed__)) sev_data_send_update_data {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In/Out */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct __attribute__((__packed__)) sev_data_send_update_vmsa {
+ u32 handle; /* In */
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In/Out */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_send_finish - SEND_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct __attribute__((__packed__)) sev_data_send_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_receive_start - RECEIVE_START command parameters
+ *
+ * @handle: handle of the VM to perform receive operation
+ * @pdh_cert_address: system physical address containing PDH certificate blob
+ * @pdh_cert_len: len of PDH certificate blob
+ * @session_address: system physical address containing session blob
+ * @session_len: len of session blob
+ */
+struct __attribute__((__packed__)) sev_data_receive_start {
+ u32 handle; /* In/Out */
+ u32 policy; /* In */
+ u64 pdh_cert_address; /* In */
+ u32 pdh_cert_len; /* In */
+ u32 reserved1;
+ u64 session_address; /* In */
+ u32 session_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_update_data - RECEIVE_UPDATE_DATA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct __attribute__((__packed__)) sev_data_receive_update_data {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_update_vmsa - RECEIVE_UPDATE_VMSA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct __attribute__((__packed__)) sev_data_receive_update_vmsa {
+ u32 handle; /* In */
+ u32 reserved1;
+ u64 hdr_address; /* In */
+ u32 hdr_len; /* In */
+ u32 reserved2;
+ u64 guest_address; /* In */
+ u32 guest_len; /* In */
+ u32 reserved3;
+ u64 trans_address; /* In */
+ u32 trans_len; /* In */
+};
+
+/**
+ * struct sev_data_receive_finish - RECEIVE_FINISH command parameters
+ *
+ * @handle: handle of the VM to finish
+ */
+struct __attribute__((__packed__)) sev_data_receive_finish {
+ u32 handle; /* In */
+};
+
+/**
+ * struct sev_data_dbg - DBG_ENCRYPT/DBG_DECRYPT command parameters
+ *
+ * @handle: handle of the VM to perform debug operation
+ * @src_addr: source address of data to operate on
+ * @dst_addr: destination address of data to operate on
+ * @len: len of data to operate on
+ */
+struct __attribute__((__packed__)) sev_data_dbg {
+ u32 handle; /* In */
+ u32 reserved;
+ u64 src_addr; /* In */
+ u64 dst_addr; /* In */
+ u32 len; /* In */
+};
+
+#endif /* __PSP_SEV_H__ */
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id
2017-10-04 13:13 ` [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id Brijesh Singh
@ 2017-10-05 20:56 ` Borislav Petkov
2017-10-08 21:14 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-05 20:56 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Wed, Oct 04, 2017 at 08:13:52AM -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.
>
> [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Gary Hook <gary.hook@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> include/linux/psp-sev.h | 515 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 515 insertions(+)
> create mode 100644 include/linux/psp-sev.h
Some fixes ontop below.
With that:
Reviewed-by: Borislav Petkov <bp@suse.de>
---
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index f01d0e3b09b8..496375d7f6a9 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -122,12 +122,12 @@ enum psp_ret_code {
* @tmr_address: system physical address used for SEV-ES
* @tmr_len: len of tmr_address
*/
-struct __attribute__((__packed__)) sev_data_init {
+struct sev_data_init {
u32 flags; /* In */
u32 reserved; /* In */
u64 tmr_address; /* In */
u32 tmr_len; /* In */
-};
+} __packed;
/**
* struct sev_data_status - PLATFORM_STATUS command parameters
@@ -140,7 +140,7 @@ struct __attribute__((__packed__)) sev_data_init {
* @build: firmware build id for API version
* @guest_count: number of active guests
*/
-struct __attribute__((__packed__)) sev_data_status {
+struct sev_data_status {
u8 api_major; /* Out */
u8 api_minor; /* Out */
u8 state; /* Out */
@@ -150,7 +150,7 @@ struct __attribute__((__packed__)) sev_data_status {
u32 reserved2 : 23;
u32 build : 8; /* Out */
u32 guest_count; /* Out */
-};
+} __packed;
/**
* struct sev_data_pek_csr - PEK_CSR command parameters
@@ -158,10 +158,10 @@ struct __attribute__((__packed__)) sev_data_status {
* @address: PEK certificate chain
* @len: len of certificate
*/
-struct __attribute__((__packed__)) sev_data_pek_csr {
+struct sev_data_pek_csr {
u64 address; /* In */
u32 len; /* In/Out */
-};
+} __packed;
/**
* struct sev_data_cert_import - PEK_CERT_IMPORT command parameters
@@ -171,13 +171,13 @@ struct __attribute__((__packed__)) sev_data_pek_csr {
* @oca_address: OCA certificate chain
* @oca_len: len of OCA certificate
*/
-struct __attribute__((__packed__)) sev_data_pek_cert_import {
+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
@@ -187,22 +187,22 @@ struct __attribute__((__packed__)) sev_data_pek_cert_import {
* @cert_chain_address: PDH certificate chain
* @cert_chain_len: len of PDH certificate chain
*/
-struct __attribute__((__packed__)) sev_data_pdh_cert_export {
+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 __attribute__((__packed__)) sev_data_decommission {
+struct sev_data_decommission {
u32 handle; /* In */
-};
+} __packed;
/**
* struct sev_data_activate - ACTIVATE command parameters
@@ -210,19 +210,19 @@ struct __attribute__((__packed__)) sev_data_decommission {
* @handle: handle of the VM to activate
* @asid: asid assigned to the VM
*/
-struct __attribute__((__packed__)) sev_data_activate {
+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 __attribute__((__packed__)) sev_data_deactivate {
+struct sev_data_deactivate {
u32 handle; /* In */
-};
+} __packed;
/**
* struct sev_data_guest_status - SEV GUEST_STATUS command parameters
@@ -232,12 +232,12 @@ struct __attribute__((__packed__)) sev_data_deactivate {
* @asid: current ASID of the VM
* @state: current state of the VM
*/
-struct __attribute__((__packed__)) sev_data_guest_status {
+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
@@ -249,7 +249,7 @@ struct __attribute__((__packed__)) sev_data_guest_status {
* @session_address: physical address of session parameters
* @session_len: len of session parameters
*/
-struct __attribute__((__packed__)) sev_data_launch_start {
+struct sev_data_launch_start {
u32 handle; /* In/Out */
u32 policy; /* In */
u64 dh_cert_address; /* In */
@@ -257,7 +257,7 @@ struct __attribute__((__packed__)) sev_data_launch_start {
u32 reserved; /* In */
u64 session_address; /* In */
u32 session_len; /* In */
-};
+} __packed;
/**
* struct sev_data_launch_update_data - LAUNCH_UPDATE_DATA command parameter
@@ -266,12 +266,12 @@ struct __attribute__((__packed__)) sev_data_launch_start {
* @len: len of memory to be encrypted
* @address: physical address of memory region to encrypt
*/
-struct __attribute__((__packed__)) sev_data_launch_update_data {
+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
@@ -280,12 +280,12 @@ struct __attribute__((__packed__)) sev_data_launch_update_data {
* @address: physical address of memory region to encrypt
* @len: len of memory region to encrypt
*/
-struct __attribute__((__packed__)) sev_data_launch_update_vmsa {
+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
@@ -294,12 +294,12 @@ struct __attribute__((__packed__)) sev_data_launch_update_vmsa {
* @address: physical address containing the measurement blob
* @len: len of measurement blob
*/
-struct __attribute__((__packed__)) sev_data_launch_measure {
+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
@@ -312,7 +312,7 @@ struct __attribute__((__packed__)) sev_data_launch_measure {
* @trans_address: physical address of transport memory buffer
* @trans_len: len of transport memory buffer
*/
-struct __attribute__((__packed__)) sev_data_launch_secret {
+struct sev_data_launch_secret {
u32 handle; /* In */
u32 reserved1;
u64 hdr_address; /* In */
@@ -323,16 +323,16 @@ struct __attribute__((__packed__)) sev_data_launch_secret {
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 __attribute__((__packed__)) sev_data_launch_finish {
+struct sev_data_launch_finish {
u32 handle; /* In */
-};
+} __packed;
/**
* struct sev_data_send_start - SEND_START command parameters
@@ -348,7 +348,7 @@ struct __attribute__((__packed__)) sev_data_launch_finish {
* @session_address: physical address containing Session data
* @session_len: len of session data
*/
-struct __attribute__((__packed__)) sev_data_send_start {
+struct sev_data_send_start {
u32 handle; /* In */
u32 policy; /* Out */
u64 pdh_cert_address; /* In */
@@ -362,7 +362,7 @@ struct __attribute__((__packed__)) sev_data_send_start {
u32 reserved3;
u64 session_address; /* In */
u32 session_len; /* In/Out */
-};
+} __packed;
/**
* struct sev_data_send_update - SEND_UPDATE_DATA command
@@ -375,7 +375,7 @@ struct __attribute__((__packed__)) sev_data_send_start {
* @trans_address: physical address of host memory region
* @trans_len: len of host memory region
*/
-struct __attribute__((__packed__)) sev_data_send_update_data {
+struct sev_data_send_update_data {
u32 handle; /* In */
u32 reserved1;
u64 hdr_address; /* In */
@@ -386,7 +386,7 @@ struct __attribute__((__packed__)) sev_data_send_update_data {
u32 reserved3;
u64 trans_address; /* In */
u32 trans_len; /* In */
-};
+} __packed;
/**
* struct sev_data_send_update - SEND_UPDATE_VMSA command
@@ -399,7 +399,7 @@ struct __attribute__((__packed__)) sev_data_send_update_data {
* @trans_address: physical address of host memory region
* @trans_len: len of host memory region
*/
-struct __attribute__((__packed__)) sev_data_send_update_vmsa {
+struct sev_data_send_update_vmsa {
u32 handle; /* In */
u64 hdr_address; /* In */
u32 hdr_len; /* In/Out */
@@ -409,16 +409,16 @@ struct __attribute__((__packed__)) sev_data_send_update_vmsa {
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 __attribute__((__packed__)) sev_data_send_finish {
+struct sev_data_send_finish {
u32 handle; /* In */
-};
+} __packed;
/**
* struct sev_data_receive_start - RECEIVE_START command parameters
@@ -429,7 +429,7 @@ struct __attribute__((__packed__)) sev_data_send_finish {
* @session_address: system physical address containing session blob
* @session_len: len of session blob
*/
-struct __attribute__((__packed__)) sev_data_receive_start {
+struct sev_data_receive_start {
u32 handle; /* In/Out */
u32 policy; /* In */
u64 pdh_cert_address; /* In */
@@ -437,7 +437,7 @@ struct __attribute__((__packed__)) sev_data_receive_start {
u32 reserved1;
u64 session_address; /* In */
u32 session_len; /* In */
-};
+} __packed;
/**
* struct sev_data_receive_update_data - RECEIVE_UPDATE_DATA command parameters
@@ -450,7 +450,7 @@ struct __attribute__((__packed__)) sev_data_receive_start {
* @trans_address: system physical address of transport buffer
* @trans_len: len of transport buffer
*/
-struct __attribute__((__packed__)) sev_data_receive_update_data {
+struct sev_data_receive_update_data {
u32 handle; /* In */
u32 reserved1;
u64 hdr_address; /* In */
@@ -461,7 +461,7 @@ struct __attribute__((__packed__)) sev_data_receive_update_data {
u32 reserved3;
u64 trans_address; /* In */
u32 trans_len; /* In */
-};
+} __packed;
/**
* struct sev_data_receive_update_vmsa - RECEIVE_UPDATE_VMSA command parameters
@@ -474,7 +474,7 @@ struct __attribute__((__packed__)) sev_data_receive_update_data {
* @trans_address: system physical address of transport buffer
* @trans_len: len of transport buffer
*/
-struct __attribute__((__packed__)) sev_data_receive_update_vmsa {
+struct sev_data_receive_update_vmsa {
u32 handle; /* In */
u32 reserved1;
u64 hdr_address; /* In */
@@ -485,16 +485,16 @@ struct __attribute__((__packed__)) sev_data_receive_update_vmsa {
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 __attribute__((__packed__)) sev_data_receive_finish {
+struct sev_data_receive_finish {
u32 handle; /* In */
-};
+} __packed;
/**
* struct sev_data_dbg - DBG_ENCRYPT/DBG_DECRYPT command parameters
@@ -504,12 +504,12 @@ struct __attribute__((__packed__)) sev_data_receive_finish {
* @dst_addr: destination address of data to operate on
* @len: len of data to operate on
*/
-struct __attribute__((__packed__)) sev_data_dbg {
+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__ */
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id
2017-10-05 20:56 ` Borislav Petkov
@ 2017-10-08 21:14 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-08 21:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 10/5/17 3:56 PM, Borislav Petkov wrote:
> On Wed, Oct 04, 2017 at 08:13:52AM -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.
>>
>> [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
>>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: Gary Hook <gary.hook@amd.com>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> Cc: linux-crypto@vger.kernel.org
>> Cc: kvm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> include/linux/psp-sev.h | 515 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 515 insertions(+)
>> create mode 100644 include/linux/psp-sev.h
> Some fixes ontop below.
>
> With that:
>
> Reviewed-by: Borislav Petkov <bp@suse.de>
Thanks, I have applied your fixes.
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (10 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 11/31] crypto: ccp: Define SEV key management command id Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-06 18:49 ` Borislav Petkov
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
2017-10-04 13:13 ` [Part2 PATCH v5 13/31] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
` (16 subsequent siblings)
28 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Borislav Petkov, Herbert Xu, Gary Hook, Tom Lendacky,
linux-crypto
AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory
contents of a virtual machines to be transparently encrypted with a key
unique to the guest VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP), which exposes the
commands for these tasks. The complete spec is available at:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
Extend the AMD-SP driver to provide the following support:
- an in-kernel APIs to communicate with a SEV firmware. The APIs can be
used by the hypervisor to create encryption context for the SEV guests.
- 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
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/psp-dev.c | 734 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 17 +
include/linux/psp-sev.h | 159 ++++++++++
include/uapi/linux/psp-sev.h | 116 +++++++
4 files changed, 1026 insertions(+)
create mode 100644 include/uapi/linux/psp-sev.h
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 7480d4316239..1b87a699bd3f 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -23,9 +23,20 @@
#include <linux/hw_random.h>
#include <linux/ccp.h>
+#include <uapi/linux/psp-sev.h>
+
#include "sp-dev.h"
#include "psp-dev.h"
+#define DEVICE_NAME "sev"
+
+static unsigned int sev_poll;
+module_param(sev_poll, uint, 0444);
+MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
+
+DEFINE_MUTEX(sev_cmd_mutex);
+static bool sev_fops_registered;
+
const struct psp_vdata psp_entry = {
.offset = 0x10500,
};
@@ -49,9 +60,725 @@ 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;
+
+ /* read the interrupt status */
+ status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
+
+ /* check if its command completion */
+ if (status & (1 << PSP_CMD_COMPLETE_REG)) {
+ int reg;
+
+ /* check if its SEV command completion */
+ reg = ioread32(psp->io_regs + PSP_CMDRESP);
+ if (reg & PSP_CMDRESP_RESP) {
+ psp->sev_int_rcvd = 1;
+ wake_up(&psp->sev_int_queue);
+ }
+ }
+
+ /* clear the interrupt status by writing 1 */
+ iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
+
return IRQ_HANDLED;
}
+static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
+ unsigned int *reg)
+{
+ int wait = timeout * 10; /* 100ms sleep => timeout * 10 */
+
+ while (--wait) {
+ msleep(100);
+
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+ if (*reg & PSP_CMDRESP_RESP)
+ break;
+ }
+
+ if (!wait) {
+ dev_err(psp->dev, "sev command timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
+{
+ psp->sev_int_rcvd = 0;
+
+ wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+
+ return 0;
+}
+
+static int sev_wait_cmd(struct psp_device *psp, unsigned int *reg)
+{
+ return (*reg & PSP_CMDRESP_IOC) ? sev_wait_cmd_ioc(psp, reg)
+ : sev_wait_cmd_poll(psp, 10, reg);
+}
+
+static int sev_cmd_buffer_len(int cmd)
+{
+ switch (cmd) {
+ case SEV_CMD_INIT: return sizeof(struct sev_data_init);
+ case SEV_CMD_PLATFORM_STATUS: return sizeof(struct sev_data_status);
+ case SEV_CMD_PEK_CSR: return sizeof(struct sev_data_pek_csr);
+ case SEV_CMD_PEK_CERT_IMPORT: return sizeof(struct sev_data_pek_cert_import);
+ case SEV_CMD_PDH_CERT_EXPORT: return sizeof(struct sev_data_pdh_cert_export);
+ case SEV_CMD_LAUNCH_START: return sizeof(struct sev_data_launch_start);
+ case SEV_CMD_LAUNCH_UPDATE_DATA: return sizeof(struct sev_data_launch_update_data);
+ case SEV_CMD_LAUNCH_UPDATE_VMSA: return sizeof(struct sev_data_launch_update_vmsa);
+ case SEV_CMD_LAUNCH_FINISH: return sizeof(struct sev_data_launch_finish);
+ case SEV_CMD_LAUNCH_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_handle_cmd(int cmd, void *data, int *psp_ret)
+{
+ struct sp_device *sp = sp_get_psp_master_device();
+ unsigned int phys_lsb, phys_msb;
+ struct psp_device *psp = sp->psp_data;
+ unsigned int reg, ret;
+
+ 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 |= sev_poll ? 0 : PSP_CMDRESP_IOC;
+ iowrite32(reg, psp->io_regs + PSP_CMDRESP);
+
+ ret = sev_wait_cmd(psp, ®);
+ if (ret)
+ goto unlock;
+
+ if (psp_ret)
+ *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
+
+ if (reg & PSP_CMDRESP_ERR_MASK) {
+ dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
+ cmd, reg & PSP_CMDRESP_ERR_MASK);
+ ret = -EIO;
+ }
+
+unlock:
+ mutex_unlock(&sev_cmd_mutex);
+ print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+ sev_cmd_buffer_len(cmd), false);
+ return ret;
+}
+
+static int sev_platform_get_state(int *state, int *error)
+{
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+ if (!ret)
+ *state = data->state;
+
+ kfree(data);
+ return ret;
+}
+
+static int sev_firmware_init(int *error)
+{
+ struct sev_data_init *data;
+ int rc;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ rc = sev_handle_cmd(SEV_CMD_INIT, data, error);
+
+ kfree(data);
+ return rc;
+}
+
+static inline int sev_ioctl_factory_reset(struct sev_issue_cmd *argp)
+{
+ return sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &argp->error);
+}
+
+static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_status out;
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
+ if (ret)
+ goto e_free;
+
+ out.api_major = data->api_major;
+ out.api_minor = data->api_minor;
+ out.state = data->state;
+ out.owner = data->owner;
+ out.config = data->config;
+ out.build = data->build;
+ out.guest_count = data->guest_count;
+ if (copy_to_user((void __user *)(uintptr_t) argp->data,
+ &out, sizeof(struct sev_user_data_status))) {
+ ret = -EFAULT;
+ goto e_free;
+ }
+
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static void *copy_user_blob(u64 __user uaddr, u32 len)
+{
+ void *data;
+
+ if (!uaddr || !len)
+ return ERR_PTR(-EINVAL);
+
+ /* verify that blob length does not exceed our limit */
+ if (len > SEV_FW_BLOB_MAX_SIZE)
+ return ERR_PTR(-EINVAL);
+
+ data = kmalloc(len, GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ goto e_free;
+
+ return data;
+
+e_free:
+ kfree(data);
+ return ERR_PTR(-EFAULT);
+}
+
+static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_csr input;
+ struct sev_data_pek_csr *data;
+ int do_shutdown = 0;
+ int ret, state;
+ void *blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pek_csr)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+
+ /* copy the PEK certificate blob from userspace */
+ blob = NULL;
+ if (input.address) {
+ blob = copy_user_blob(input.address, input.length);
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ goto e_free;
+ }
+
+ data->address = __psp_pa(blob);
+ data->len = input.length;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_blob;
+
+ /*
+ * PEK_CERT command can be issued only when we are in INIT state.
+ * if current state is WORKING then reject it, if state is UNINIT
+ * then transition the platform to INIT state before issuing the
+ * command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_blob;
+ } else if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_blob;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+ input.length = data->len;
+
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pek_csr)))
+ ret = -EFAULT;
+
+ /* transition the plaform into INIT state */
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
+{
+ int ret, state, do_shutdown = 0;
+
+ /*
+ * PDH_GEN command can be issued when platform is in INIT or WORKING
+ * state. If we are in UNINIT state then transition into INIT state
+ * before issuing the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_UNINIT) {
+ /* transition the plaform into INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
+static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
+{
+ int do_shutdown = 0;
+ int ret, state;
+
+ /*
+ * PEK_GEN command can be issued only when firmware is in INIT state.
+ * If firmware is in UNINIT state then we transition it into INIT state
+ * and issue the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_WORKING) {
+ return -EBUSY;
+ } else if (state == SEV_STATE_UNINIT) {
+ /* transition the plaform into INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
+static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_cert_import input;
+ struct sev_data_pek_cert_import *data;
+ int ret, state, do_shutdown = 0;
+ void *pek_blob, *oca_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t) argp->data,
+ sizeof(struct sev_user_data_pek_cert_import)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* copy PEK certificate blobs from userspace */
+ pek_blob = copy_user_blob(input.pek_cert_address, input.pek_cert_len);
+ if (IS_ERR(pek_blob)) {
+ ret = PTR_ERR(pek_blob);
+ goto e_free;
+ }
+
+ data->pek_cert_address = __psp_pa(pek_blob);
+ data->pek_cert_len = input.pek_cert_len;
+
+ /* copy PEK certificate blobs from userspace */
+ oca_blob = copy_user_blob(input.oca_cert_address, input.oca_cert_len);
+ if (IS_ERR(oca_blob)) {
+ ret = PTR_ERR(oca_blob);
+ goto e_free_pek;
+ }
+
+ data->oca_cert_address = __psp_pa(oca_blob);
+ data->oca_cert_len = input.oca_cert_len;
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_oca;
+
+ /*
+ * PEK_CERT_IMPORT command can be issued only when platform is in INIT
+ * state. If we are in UNINIT state then transition into INIT state
+ * before issuing the command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_oca;
+ } else if (state == SEV_STATE_UNINIT) {
+ /* transition platform init INIT state */
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_oca;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+e_free_oca:
+ kfree(oca_blob);
+e_free_pek:
+ kfree(pek_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pdh_cert_export input;
+ struct sev_data_pdh_cert_export *data;
+ int ret, state, need_shutdown = 0;
+ void *pdh_blob, *cert_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ pdh_blob = NULL;
+ if (input.pdh_cert_address) {
+ if (!access_ok(VERIFY_WRITE, input.pdh_cert_address,
+ input.pdh_cert_len)) {
+ ret = -EFAULT;
+ goto e_free;
+ }
+
+ if (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free;
+ }
+
+ pdh_blob = kmalloc(input.pdh_cert_len, GFP_KERNEL);
+ if (!pdh_blob) {
+ ret = -ENOMEM;
+ goto e_free;
+ }
+
+ data->pdh_cert_address = __psp_pa(pdh_blob);
+ data->pdh_cert_len = input.pdh_cert_len;
+ }
+
+ cert_blob = NULL;
+ if (input.cert_chain_address) {
+ if (!access_ok(VERIFY_WRITE, input.cert_chain_address,
+ input.cert_chain_len)) {
+ ret = -EFAULT;
+ goto e_free_pdh;
+ }
+
+ if (input.cert_chain_len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free_pdh;
+ }
+
+ cert_blob = kmalloc(input.cert_chain_len, GFP_KERNEL);
+ if (!cert_blob) {
+ ret = -ENOMEM;
+ goto e_free_pdh;
+ }
+
+ data->cert_chain_address = __psp_pa(cert_blob);
+ data->cert_chain_len = input.cert_chain_len;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ /*
+ * CERT_EXPORT command can be issued in INIT or WORKING state.
+ * If we are in UNINIT state then transition into INIT state and
+ * shutdown before exiting. But if platform is in WORKING state
+ * then EXPORT the certificate but do not shutdown the platform.
+ */
+ if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ need_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+
+ input.cert_chain_len = data->cert_chain_len;
+ input.pdh_cert_len = data->pdh_cert_len;
+
+ /* copy certificate length to userspace */
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ ret = -EFAULT;
+
+ if (ret)
+ goto e_shutdown;
+
+ /* copy PDH certificate to userspace */
+ if (pdh_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.pdh_cert_address,
+ pdh_blob, input.pdh_cert_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+ /* copy certificate chain to userspace */
+ if (cert_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.cert_chain_address,
+ cert_blob, input.cert_chain_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+e_shutdown:
+ if (need_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+e_free_cert:
+ kfree(cert_blob);
+e_free_pdh:
+ kfree(pdh_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
+static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
+{
+ void __user *argp = (void __user *)arg;
+ struct sev_issue_cmd input;
+ int ret = -EFAULT;
+
+ if (ioctl != SEV_ISSUE_CMD)
+ return -EINVAL;
+
+ if (copy_from_user(&input, argp, sizeof(struct sev_issue_cmd)))
+ return -EFAULT;
+
+ if (input.cmd > SEV_CMD_MAX)
+ return -EINVAL;
+
+ switch (input.cmd) {
+
+ case SEV_USER_CMD_FACTORY_RESET: {
+ ret = sev_ioctl_factory_reset(&input);
+ break;
+ }
+ case SEV_USER_CMD_PLATFORM_STATUS: {
+ ret = sev_ioctl_platform_status(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_GEN: {
+ ret = sev_ioctl_pek_gen(&input);
+ break;
+ }
+ case SEV_USER_CMD_PDH_GEN: {
+ ret = sev_ioctl_pdh_gen(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_CSR: {
+ ret = sev_ioctl_pek_csr(&input);
+ break;
+ }
+ case SEV_USER_CMD_PEK_CERT_IMPORT: {
+ ret = sev_ioctl_pek_cert_import(&input);
+ break;
+ }
+ case SEV_USER_CMD_PDH_CERT_EXPORT: {
+ ret = sev_ioctl_pdh_cert_export(&input);
+ break;
+ }
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
+ ret = -EFAULT;
+
+ return ret;
+}
+
+
+const struct file_operations sev_fops = {
+ .owner = THIS_MODULE,
+ .unlocked_ioctl = sev_ioctl,
+};
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_INIT, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+int sev_platform_shutdown(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_data_status *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_status);
+
+int sev_issue_cmd_external_user(struct file *filep, unsigned int cmd,
+ void *data, int *error)
+{
+ if (!filep || filep->f_op != &sev_fops)
+ return -EBADF;
+
+ return sev_handle_cmd(cmd, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_issue_cmd_external_user);
+
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DEACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_deactivate);
+
+int sev_guest_activate(struct sev_data_activate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_ACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_activate);
+
+int sev_guest_decommission(struct sev_data_decommission *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DECOMMISSION, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_decommission);
+
+int sev_guest_df_flush(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DF_FLUSH, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_df_flush);
+
+static int sev_ops_init(struct psp_device *psp)
+{
+ struct miscdevice *misc = &psp->sev_misc;
+ int ret = 0;
+
+ /*
+ * SEV feature support can be detected on the multiple devices but the
+ * SEV FW commands must be issued on the master. During probe time we
+ * do not know the master hence we create /dev/sev on the first device
+ * probe. sev_handle_cmd() finds the right master device to when issuing
+ * the command to the firmware.
+ */
+ if (!sev_fops_registered) {
+ misc->minor = MISC_DYNAMIC_MINOR;
+ misc->name = DEVICE_NAME;
+ misc->fops = &sev_fops;
+
+ ret = misc_register(misc);
+ if (!ret) {
+ sev_fops_registered = true;
+ psp->has_sev_fops = true;
+ init_waitqueue_head(&psp->sev_int_queue);
+ dev_info(psp->dev, "registered SEV device\n");
+ }
+ }
+
+ return ret;
+}
+
+static int sev_init(struct psp_device *psp)
+{
+ /* Check if device supports SEV feature */
+ if (!(ioread32(psp->io_regs + PSP_FEATURE_REG) & 1)) {
+ dev_dbg(psp->dev, "device does not support SEV\n");
+ return 1;
+ }
+
+ return sev_ops_init(psp);
+}
+
+static void sev_exit(struct psp_device *psp)
+{
+ if (psp->has_sev_fops)
+ misc_deregister(&psp->sev_misc);
+}
+
int psp_dev_init(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -88,11 +815,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;
@@ -105,5 +838,6 @@ void psp_dev_destroy(struct sp_device *sp)
{
struct psp_device *psp = sp->psp_data;
+ sev_exit(psp);
sp_free_psp_irq(sp, psp);
}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index d53970ef5960..51d3cd966eed 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -25,9 +25,21 @@
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
#include <linux/dmaengine.h>
+#include <linux/psp-sev.h>
+#include <linux/miscdevice.h>
#include "sp-dev.h"
+#define PSP_C2PMSG(_num) ((_num) << 2)
+#define PSP_CMDRESP PSP_C2PMSG(32)
+#define PSP_CMDBUFF_ADDR_LO PSP_C2PMSG(56)
+#define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
+#define PSP_FEATURE_REG PSP_C2PMSG(63)
+
+#define PSP_P2CMSG(_num) (_num << 2)
+#define PSP_CMD_COMPLETE_REG 1
+#define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
+
#define PSP_P2CMSG_INTEN 0x0110
#define PSP_P2CMSG_INTSTS 0x0114
@@ -54,6 +66,11 @@ struct psp_device {
struct sp_device *sp;
void __iomem *io_regs;
+
+ unsigned int sev_int_rcvd;
+ wait_queue_head_t sev_int_queue;
+ bool has_sev_fops;
+ struct miscdevice sev_misc;
};
extern const struct psp_vdata psp_entry;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index f01d0e3b09b8..ad7708803821 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -512,4 +512,163 @@ struct __attribute__((__packed__)) sev_data_dbg {
u32 len; /* In */
};
+#if defined(CONFIG_CRYPTO_DEV_SP_PSP)
+
+/**
+ * sev_platform_init - perform SEV INIT command
+ *
+ * @init: sev_data_init structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_init(struct sev_data_init *init, int *error);
+
+/**
+ * sev_platform_shutdown - perform SEV SHUTDOWN command
+ *
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_shutdown(int *error);
+
+/**
+ * sev_platform_status - perform SEV PLATFORM_STATUS command
+ *
+ * @init: sev_data_status structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_status(struct sev_data_status *status, int *error);
+
+/**
+ * sev_issue_cmd_external_user - issue SEV command by other driver with a file
+ * handle.
+ *
+ * The function can be used by other drivers to issue a SEV command on
+ * behalf by userspace. The caller must pass a valid SEV file descriptor
+ * so that we know that caller has access to SEV device.
+ *
+ * @filep - SEV device file pointer
+ * @cmd - command to issue
+ * @data - command buffer
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ * -%EINVAL if the SEV file descriptor is not valid
+ */
+int sev_issue_cmd_external_user(struct file *filep, unsigned int id,
+ void *data, int *error);
+
+/**
+ * sev_guest_deactivate - perform SEV DEACTIVATE command
+ *
+ * @deactivate: sev_data_deactivate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error);
+
+/**
+ * sev_guest_activate - perform SEV ACTIVATE command
+ *
+ * @activate: sev_data_activate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_activate(struct sev_data_activate *data, int *error);
+
+/**
+ * sev_guest_df_flush - perform SEV DF_FLUSH command
+ *
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_df_flush(int *error);
+
+/**
+ * sev_guest_decommission - perform SEV DECOMMISSION command
+ *
+ * @decommission: sev_data_decommission structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_decommission(struct sev_data_decommission *data, int *error);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int
+sev_platform_status(struct sev_data_status *status, int *error) { return -ENODEV; }
+
+static inline int
+sev_platform_init(struct sev_data_init *init, int *error) { return -ENODEV; }
+
+static inline int sev_platform_shutdown(int *error) { return -ENODEV; }
+
+static inline int
+sev_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__ */
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
new file mode 100644
index 000000000000..e41e4bed246a
--- /dev/null
+++ b/include/uapi/linux/psp-sev.h
@@ -0,0 +1,116 @@
+
+/*
+ * 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_USER_CMD_FACTORY_RESET = 0,
+ SEV_USER_CMD_PLATFORM_STATUS,
+ SEV_USER_CMD_PEK_GEN,
+ SEV_USER_CMD_PEK_CSR,
+ SEV_USER_CMD_PDH_GEN,
+ SEV_USER_CMD_PDH_CERT_EXPORT,
+ SEV_USER_CMD_PEK_CERT_IMPORT,
+
+ SEV_USER_CMD_MAX,
+};
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u8 owner; /* Out */
+ __u32 config; /* Out */
+ __u8 build; /* Out */
+ __u32 guest_count; /* Out */
+};
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+ __u64 address; /* In */
+ __u32 length; /* In/Out */
+};
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+ __u64 pek_cert_address; /* In */
+ __u32 pek_cert_len; /* In */
+ __u64 oca_cert_address; /* In */
+ __u32 oca_cert_len; /* In */
+};
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+ __u64 pdh_cert_address; /* In */
+ __u32 pdh_cert_len; /* In/Out */
+ __u64 cert_chain_address; /* In */
+ __u32 cert_chain_len; /* In/Out */
+};
+
+/**
+ * struct sev_issue_cmd - SEV ioctl parameters
+ *
+ * @cmd: SEV commands to execute
+ * @opaque: pointer to the command structure
+ * @error: SEV FW return code on failure
+ */
+struct sev_issue_cmd {
+ __u32 cmd; /* In */
+ __u64 data; /* In */
+ __u32 error; /* Out */
+};
+
+#define SEV_IOC_TYPE 'S'
+#define SEV_ISSUE_CMD _IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
+
+#endif /* __PSP_USER_SEV_H */
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-04 13:13 ` [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-10-06 18:49 ` Borislav Petkov
2017-10-06 19:48 ` Brijesh Singh
2017-10-07 18:13 ` Brijesh Singh
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
1 sibling, 2 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-06 18:49 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On Wed, Oct 04, 2017 at 08:13:53AM -0500, Brijesh Singh wrote:
> AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory
> contents of a virtual machines to be transparently encrypted with a key
> unique to the guest VM. The programming and management of the encryption
> keys are handled by the AMD Secure Processor (AMD-SP), which exposes the
> commands for these tasks. The complete spec is available at:
>
> http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
>
> Extend the AMD-SP driver to provide the following support:
>
> - an in-kernel APIs to communicate with a SEV firmware. The APIs can be
> used by the hypervisor to create encryption context for the SEV guests.
>
> - a userspace IOCTL to manage the platform certificates
Change that commit message to:
"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
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> drivers/crypto/ccp/psp-dev.c | 734 +++++++++++++++++++++++++++++++++++++++++++
> drivers/crypto/ccp/psp-dev.h | 17 +
> include/linux/psp-sev.h | 159 ++++++++++
> include/uapi/linux/psp-sev.h | 116 +++++++
> 4 files changed, 1026 insertions(+)
> create mode 100644 include/uapi/linux/psp-sev.h
>
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 7480d4316239..1b87a699bd3f 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -23,9 +23,20 @@
> #include <linux/hw_random.h>
> #include <linux/ccp.h>
>
> +#include <uapi/linux/psp-sev.h>
> +
> #include "sp-dev.h"
> #include "psp-dev.h"
>
> +#define DEVICE_NAME "sev"
> +
> +static unsigned int sev_poll;
> +module_param(sev_poll, uint, 0444);
> +MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
What is that used for? Some debugging leftover probably? If not, add a
comment for why it is useful.
> +
> +DEFINE_MUTEX(sev_cmd_mutex);
> +static bool sev_fops_registered;
> +
> const struct psp_vdata psp_entry = {
> .offset = 0x10500,
> };
> @@ -49,9 +60,725 @@ 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;
> +
> + /* read the interrupt status */
> + status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
> +
> + /* check if its command completion */
> + if (status & (1 << PSP_CMD_COMPLETE_REG)) {
> + int reg;
> +
> + /* check if its SEV command completion */
> + reg = ioread32(psp->io_regs + PSP_CMDRESP);
> + if (reg & PSP_CMDRESP_RESP) {
> + psp->sev_int_rcvd = 1;
> + wake_up(&psp->sev_int_queue);
> + }
> + }
> +
> + /* clear the interrupt status by writing 1 */
> + iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
> +
> return IRQ_HANDLED;
> }
>
> +static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
> + unsigned int *reg)
> +{
> + int wait = timeout * 10; /* 100ms sleep => timeout * 10 */
How is this a 100ms sleep?!
10 * 10 * 100ms = 10000ms = 10 seconds max sleep is what my math says.
> +
> + while (--wait) {
> + msleep(100);
> +
> + *reg = ioread32(psp->io_regs + PSP_CMDRESP);
> + if (*reg & PSP_CMDRESP_RESP)
> + break;
> + }
> +
> + if (!wait) {
> + dev_err(psp->dev, "sev command timed out\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}
> +
> +static int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
> +{
> + psp->sev_int_rcvd = 0;
> +
> + wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
What happens if the command times out and it never sets psp->sev_int_rcvd?
> + *reg = ioread32(psp->io_regs + PSP_CMDRESP);
> +
> + return 0;
> +}
> +
> +static int sev_wait_cmd(struct psp_device *psp, unsigned int *reg)
> +{
> + return (*reg & PSP_CMDRESP_IOC) ? sev_wait_cmd_ioc(psp, reg)
> + : sev_wait_cmd_poll(psp, 10, reg);
> +}
> +
> +static int sev_cmd_buffer_len(int cmd)
> +{
> + switch (cmd) {
> + case SEV_CMD_INIT: return sizeof(struct sev_data_init);
> + case SEV_CMD_PLATFORM_STATUS: return sizeof(struct sev_data_status);
> + case SEV_CMD_PEK_CSR: return sizeof(struct sev_data_pek_csr);
> + case SEV_CMD_PEK_CERT_IMPORT: return sizeof(struct sev_data_pek_cert_import);
> + case SEV_CMD_PDH_CERT_EXPORT: return sizeof(struct sev_data_pdh_cert_export);
> + case SEV_CMD_LAUNCH_START: return sizeof(struct sev_data_launch_start);
> + case SEV_CMD_LAUNCH_UPDATE_DATA: return sizeof(struct sev_data_launch_update_data);
> + case SEV_CMD_LAUNCH_UPDATE_VMSA: return sizeof(struct sev_data_launch_update_vmsa);
> + case SEV_CMD_LAUNCH_FINISH: return sizeof(struct sev_data_launch_finish);
> + case SEV_CMD_LAUNCH_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_handle_cmd(int cmd, void *data, int *psp_ret)
> +{
> + struct sp_device *sp = sp_get_psp_master_device();
> + unsigned int phys_lsb, phys_msb;
> + struct psp_device *psp = sp->psp_data;
> + unsigned int reg, ret;
> +
> + 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 |= sev_poll ? 0 : PSP_CMDRESP_IOC;
> + iowrite32(reg, psp->io_regs + PSP_CMDRESP);
> +
> + ret = sev_wait_cmd(psp, ®);
> + if (ret)
> + goto unlock;
> +
> + if (psp_ret)
> + *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
> +
> + if (reg & PSP_CMDRESP_ERR_MASK) {
> + dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
> + cmd, reg & PSP_CMDRESP_ERR_MASK);
> + ret = -EIO;
> + }
> +
> +unlock:
> + mutex_unlock(&sev_cmd_mutex);
> + print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> + sev_cmd_buffer_len(cmd), false);
> + return ret;
> +}
Ok, this patch is humongous. Please split it in at least 3 or 4 separate
logical patches as it is very hard to review as one huge chunk right
now. Like, for example, the header file additions could be one patch,
then part of psp-dev.c and so on.
You can then send me those split-up ones as a reply here so that I can
take a look again.
Also, here are a bunch of fixes ontop. Please add
"Improvements by Borislav Petkov <bp@suse.de>"
to the commit message when you decide to use them.
Btw, the psp_entry thing I've moved to sp-pci.c, you probably should do
that in the patch which adds it, not here.
Also, I've fixed:
+ /* Clear the interrupt status by writing 1. */
+ iowrite32(1, psp->io_regs + PSP_P2CMSG_INTSTS);
to really write 1 and not reuse the old status value.
And so on, they should be obvious from the diff.
Thx.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 1b87a699bd3f..13633eaa7889 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -32,15 +32,11 @@
static unsigned int sev_poll;
module_param(sev_poll, uint, 0444);
-MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
+MODULE_PARM_DESC(sev_poll, "Poll for SEV command completion - any non-zero value");
-DEFINE_MUTEX(sev_cmd_mutex);
+static DEFINE_MUTEX(sev_cmd_mutex);
static bool sev_fops_registered;
-const struct psp_vdata psp_entry = {
- .offset = 0x10500,
-};
-
static struct psp_device *psp_alloc_struct(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -62,34 +58,37 @@ static irqreturn_t psp_irq_handler(int irq, void *data)
{
struct psp_device *psp = data;
unsigned int status;
+ int reg;
- /* read the interrupt status */
+ /* Read the interrupt status: */
status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
- /* check if its command completion */
- if (status & (1 << PSP_CMD_COMPLETE_REG)) {
- int reg;
+ /* Check if it is command completion: */
+ if (!(status & BIT(PSP_CMD_COMPLETE_REG)))
+ goto done;
- /* check if its SEV command completion */
- reg = ioread32(psp->io_regs + PSP_CMDRESP);
- if (reg & PSP_CMDRESP_RESP) {
- psp->sev_int_rcvd = 1;
- wake_up(&psp->sev_int_queue);
- }
+ /* 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);
}
- /* clear the interrupt status by writing 1 */
- iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
+done:
+ /* Clear the interrupt status by writing 1. */
+ iowrite32(1, psp->io_regs + PSP_P2CMSG_INTSTS);
return IRQ_HANDLED;
}
-static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
+static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeouts,
unsigned int *reg)
{
- int wait = timeout * 10; /* 100ms sleep => timeout * 10 */
+ /* 10*100ms max timeout */
+ if (timeouts > 10)
+ timeouts = 10;
- while (--wait) {
+ while (--timeouts) {
msleep(100);
*reg = ioread32(psp->io_regs + PSP_CMDRESP);
@@ -97,8 +96,8 @@ static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
break;
}
- if (!wait) {
- dev_err(psp->dev, "sev command timed out\n");
+ if (!timeouts) {
+ dev_err(psp->dev, "SEV command timed out\n");
return -ETIMEDOUT;
}
@@ -157,11 +156,16 @@ static int sev_cmd_buffer_len(int cmd)
static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
{
- struct sp_device *sp = sp_get_psp_master_device();
unsigned int phys_lsb, phys_msb;
- struct psp_device *psp = sp->psp_data;
+ struct psp_device *psp;
unsigned int reg, ret;
+ struct sp_device *sp;
+
+ sp = sp_get_psp_master_device();
+ if (!sp)
+ return -ENODEV;
+ psp = sp->psp_data;
if (!psp)
return -ENODEV;
@@ -170,9 +174,10 @@ static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
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);
+ cmd, phys_msb, phys_lsb);
+
print_hex_dump_debug("(in): ", DUMP_PREFIX_OFFSET, 16, 2, data,
- sev_cmd_buffer_len(cmd), false);
+ sev_cmd_buffer_len(cmd), false);
/* Only one command at a time... */
mutex_lock(&sev_cmd_mutex);
@@ -201,7 +206,7 @@ static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
unlock:
mutex_unlock(&sev_cmd_mutex);
print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
- sev_cmd_buffer_len(cmd), false);
+ sev_cmd_buffer_len(cmd), false);
return ret;
}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 51d3cd966eed..6e8f83b41521 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -73,6 +73,4 @@ struct psp_device {
struct miscdevice sev_misc;
};
-extern const struct psp_vdata psp_entry;
-
#endif /* __PSP_DEV_H */
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 20a0f3543cf4..f5f43c50698a 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -268,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,
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-06 18:49 ` Borislav Petkov
@ 2017-10-06 19:48 ` Brijesh Singh
2017-10-07 18:13 ` Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-06 19:48 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 10/6/17 1:49 PM, Borislav Petkov wrote:
...
>> +
>> +static unsigned int sev_poll;
>> +module_param(sev_poll, uint, 0444);
>> +MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
> What is that used for? Some debugging leftover probably? If not, add a
> comment for why it is useful.
>
Yes, it was used for debug and can be removed. I will it in next rev.
.....
> Ok, this patch is humongous. Please split it in at least 3 or 4 separate
> logical patches as it is very hard to review as one huge chunk right
> now. Like, for example, the header file additions could be one patch,
> then part of psp-dev.c and so on.
>
> You can then send me those split-up ones as a reply here so that I can
> take a look again.
I will see what I can do, Maybe I will add one command at a time like we
do in svm.c.
> Also, here are a bunch of fixes ontop. Please add
>
> "Improvements by Borislav Petkov <bp@suse.de>"
>
> to the commit message when you decide to use them.
Sure, I will add your Improved-by-tag.
> Btw, the psp_entry thing I've moved to sp-pci.c, you probably should do
> that in the patch which adds it, not here.
>
> Also, I've fixed:
>
> + /* Clear the interrupt status by writing 1. */
> + iowrite32(1, psp->io_regs + PSP_P2CMSG_INTSTS);
>
> to really write 1 and not reuse the old status value.
Actually this one is interesting. When we read the status register, one
of the bit in status register will be 1 (i.e it may not always be bit 0)
and we need to write 1 on same bit position to clear it -- basically
write the same value you read. I will improve the comment.
> And so on, they should be obvious from the diff.
>
> Thx.
>
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 1b87a699bd3f..13633eaa7889 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -32,15 +32,11 @@
>
> static unsigned int sev_poll;
> module_param(sev_poll, uint, 0444);
> -MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero value");
> +MODULE_PARM_DESC(sev_poll, "Poll for SEV command completion - any non-zero value");
>
> -DEFINE_MUTEX(sev_cmd_mutex);
> +static DEFINE_MUTEX(sev_cmd_mutex);
> static bool sev_fops_registered;
>
> -const struct psp_vdata psp_entry = {
> - .offset = 0x10500,
> -};
> -
> static struct psp_device *psp_alloc_struct(struct sp_device *sp)
> {
> struct device *dev = sp->dev;
> @@ -62,34 +58,37 @@ static irqreturn_t psp_irq_handler(int irq, void *data)
> {
> struct psp_device *psp = data;
> unsigned int status;
> + int reg;
>
> - /* read the interrupt status */
> + /* Read the interrupt status: */
> status = ioread32(psp->io_regs + PSP_P2CMSG_INTSTS);
>
> - /* check if its command completion */
> - if (status & (1 << PSP_CMD_COMPLETE_REG)) {
> - int reg;
> + /* Check if it is command completion: */
> + if (!(status & BIT(PSP_CMD_COMPLETE_REG)))
> + goto done;
>
> - /* check if its SEV command completion */
> - reg = ioread32(psp->io_regs + PSP_CMDRESP);
> - if (reg & PSP_CMDRESP_RESP) {
> - psp->sev_int_rcvd = 1;
> - wake_up(&psp->sev_int_queue);
> - }
> + /* 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);
> }
>
> - /* clear the interrupt status by writing 1 */
> - iowrite32(status, psp->io_regs + PSP_P2CMSG_INTSTS);
> +done:
> + /* Clear the interrupt status by writing 1. */
> + iowrite32(1, psp->io_regs + PSP_P2CMSG_INTSTS);
>
> return IRQ_HANDLED;
> }
>
> -static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
> +static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeouts,
> unsigned int *reg)
> {
> - int wait = timeout * 10; /* 100ms sleep => timeout * 10 */
> + /* 10*100ms max timeout */
> + if (timeouts > 10)
> + timeouts = 10;
>
> - while (--wait) {
> + while (--timeouts) {
> msleep(100);
>
> *reg = ioread32(psp->io_regs + PSP_CMDRESP);
> @@ -97,8 +96,8 @@ static int sev_wait_cmd_poll(struct psp_device *psp, unsigned int timeout,
> break;
> }
>
> - if (!wait) {
> - dev_err(psp->dev, "sev command timed out\n");
> + if (!timeouts) {
> + dev_err(psp->dev, "SEV command timed out\n");
> return -ETIMEDOUT;
> }
>
> @@ -157,11 +156,16 @@ static int sev_cmd_buffer_len(int cmd)
>
> static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
> {
> - struct sp_device *sp = sp_get_psp_master_device();
> unsigned int phys_lsb, phys_msb;
> - struct psp_device *psp = sp->psp_data;
> + struct psp_device *psp;
> unsigned int reg, ret;
> + struct sp_device *sp;
> +
> + sp = sp_get_psp_master_device();
> + if (!sp)
> + return -ENODEV;
>
> + psp = sp->psp_data;
> if (!psp)
> return -ENODEV;
>
> @@ -170,9 +174,10 @@ static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
> 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);
> + cmd, phys_msb, phys_lsb);
> +
> print_hex_dump_debug("(in): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> - sev_cmd_buffer_len(cmd), false);
> + sev_cmd_buffer_len(cmd), false);
>
> /* Only one command at a time... */
> mutex_lock(&sev_cmd_mutex);
> @@ -201,7 +206,7 @@ static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
> unlock:
> mutex_unlock(&sev_cmd_mutex);
> print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> - sev_cmd_buffer_len(cmd), false);
> + sev_cmd_buffer_len(cmd), false);
> return ret;
> }
>
> diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
> index 51d3cd966eed..6e8f83b41521 100644
> --- a/drivers/crypto/ccp/psp-dev.h
> +++ b/drivers/crypto/ccp/psp-dev.h
> @@ -73,6 +73,4 @@ struct psp_device {
> struct miscdevice sev_misc;
> };
>
> -extern const struct psp_vdata psp_entry;
> -
> #endif /* __PSP_DEV_H */
> diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
> index 20a0f3543cf4..f5f43c50698a 100644
> --- a/drivers/crypto/ccp/sp-pci.c
> +++ b/drivers/crypto/ccp/sp-pci.c
> @@ -268,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,
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-06 18:49 ` Borislav Petkov
2017-10-06 19:48 ` Brijesh Singh
@ 2017-10-07 18:13 ` Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 18:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Paolo Bonzini,
Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto
On 10/6/17 1:49 PM, Borislav Petkov wrote:
...
>> +static int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
>> +{
>> + psp->sev_int_rcvd = 0;
>> +
>> + wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
> What happens if the command times out and it never sets psp->sev_int_rcvd?
Sorry i missed replying on this comment. We should not run into cases
where after issuing PSP command we do not get an interrupt. I would
prefer to avoid adding the timeout value. At least so far in all my runs
I have not came across this situation but it can happen ;). The tricky
part is, what should be the default timeout value. Depending on the user
inputs some commands can take long time.
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-04 13:13 ` [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
2017-10-06 18:49 ` Borislav Petkov
@ 2017-10-07 1:05 ` Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
` (9 more replies)
1 sibling, 10 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:05 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
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>
---
Based on Boris feedback split this patch in 9 logical patches, they are
numbers from 12.1 to 12.9.
drivers/crypto/ccp/psp-dev.c | 244 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 17 +++
include/linux/psp-sev.h | 159 ++++++++++++++++++++++++++++
3 files changed, 420 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index b5789f878560..e9b776c3acb2 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -23,9 +23,16 @@
#include <linux/hw_random.h>
#include <linux/ccp.h>
+#include <uapi/linux/psp-sev.h>
+
#include "sp-dev.h"
#include "psp-dev.h"
+#define DEVICE_NAME "sev"
+
+static DEFINE_MUTEX(sev_cmd_mutex);
+static bool sev_fops_registered;
+
static struct psp_device *psp_alloc_struct(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -45,9 +52,239 @@ 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 int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
+{
+ psp->sev_int_rcvd = 0;
+
+ wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+
+ return 0;
+}
+
+static int sev_cmd_buffer_len(int cmd)
+{
+ switch (cmd) {
+ case SEV_CMD_INIT: return sizeof(struct sev_data_init);
+ case SEV_CMD_PLATFORM_STATUS: return sizeof(struct sev_data_status);
+ case SEV_CMD_PEK_CSR: return sizeof(struct sev_data_pek_csr);
+ case SEV_CMD_PEK_CERT_IMPORT: return sizeof(struct sev_data_pek_cert_import);
+ case SEV_CMD_PDH_CERT_EXPORT: return sizeof(struct sev_data_pdh_cert_export);
+ case SEV_CMD_LAUNCH_START: return sizeof(struct sev_data_launch_start);
+ case SEV_CMD_LAUNCH_UPDATE_DATA: return sizeof(struct sev_data_launch_update_data);
+ case SEV_CMD_LAUNCH_UPDATE_VMSA: return sizeof(struct sev_data_launch_update_vmsa);
+ case SEV_CMD_LAUNCH_FINISH: return sizeof(struct sev_data_launch_finish);
+ case SEV_CMD_LAUNCH_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_handle_cmd(int cmd, void *data, int *psp_ret)
+{
+ unsigned int phys_lsb, phys_msb;
+ struct psp_device *psp;
+ unsigned int reg, ret;
+ 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);
+
+ ret = sev_wait_cmd_ioc(psp, ®);
+ if (ret)
+ goto unlock;
+
+ if (psp_ret)
+ *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
+
+ if (reg & PSP_CMDRESP_ERR_MASK) {
+ dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
+ cmd, reg & PSP_CMDRESP_ERR_MASK);
+ ret = -EIO;
+ }
+
+unlock:
+ mutex_unlock(&sev_cmd_mutex);
+ print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+ sev_cmd_buffer_len(cmd), false);
+ return ret;
+}
+
+static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
+{
+ return -ENOTTY;
+}
+
+const struct file_operations sev_fops = {
+ .owner = THIS_MODULE,
+ .unlocked_ioctl = sev_ioctl,
+};
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_INIT, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+int sev_platform_shutdown(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_data_status *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_status);
+
+int sev_issue_cmd_external_user(struct file *filep, unsigned int cmd,
+ void *data, int *error)
+{
+ if (!filep || filep->f_op != &sev_fops)
+ return -EBADF;
+
+ return sev_handle_cmd(cmd, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_issue_cmd_external_user);
+
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DEACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_deactivate);
+
+int sev_guest_activate(struct sev_data_activate *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_ACTIVATE, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_activate);
+
+int sev_guest_decommission(struct sev_data_decommission *data, int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DECOMMISSION, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_decommission);
+
+int sev_guest_df_flush(int *error)
+{
+ return sev_handle_cmd(SEV_CMD_DF_FLUSH, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_guest_df_flush);
+
+static int sev_ops_init(struct psp_device *psp)
+{
+ struct miscdevice *misc = &psp->sev_misc;
+ int ret = 0;
+
+ /*
+ * SEV feature support can be detected on the multiple devices but the
+ * SEV FW commands must be issued on the master. During probe time we
+ * do not know the master hence we create /dev/sev on the first device
+ * probe. sev_handle_cmd() finds the right master device to when issuing
+ * the command to the firmware.
+ */
+ if (!sev_fops_registered) {
+ misc->minor = MISC_DYNAMIC_MINOR;
+ misc->name = DEVICE_NAME;
+ misc->fops = &sev_fops;
+
+ ret = misc_register(misc);
+ if (!ret) {
+ sev_fops_registered = true;
+ psp->has_sev_fops = true;
+ init_waitqueue_head(&psp->sev_int_queue);
+ dev_info(psp->dev, "registered SEV device\n");
+ }
+ }
+
+ return ret;
+}
+
+static int sev_init(struct psp_device *psp)
+{
+ /* Check if device supports SEV feature */
+ if (!(ioread32(psp->io_regs + PSP_FEATURE_REG) & 1)) {
+ dev_dbg(psp->dev, "device does not support SEV\n");
+ return 1;
+ }
+
+ return sev_ops_init(psp);
+}
+
+static void sev_exit(struct psp_device *psp)
+{
+ if (psp->has_sev_fops)
+ misc_deregister(&psp->sev_misc);
+}
+
int psp_dev_init(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -84,11 +321,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 +344,6 @@ void psp_dev_destroy(struct sp_device *sp)
{
struct psp_device *psp = sp->psp_data;
+ sev_exit(psp);
sp_free_psp_irq(sp, psp);
}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 55b7808367c3..6e8f83b41521 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -25,9 +25,21 @@
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
#include <linux/dmaengine.h>
+#include <linux/psp-sev.h>
+#include <linux/miscdevice.h>
#include "sp-dev.h"
+#define PSP_C2PMSG(_num) ((_num) << 2)
+#define PSP_CMDRESP PSP_C2PMSG(32)
+#define PSP_CMDBUFF_ADDR_LO PSP_C2PMSG(56)
+#define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
+#define PSP_FEATURE_REG PSP_C2PMSG(63)
+
+#define PSP_P2CMSG(_num) (_num << 2)
+#define PSP_CMD_COMPLETE_REG 1
+#define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
+
#define PSP_P2CMSG_INTEN 0x0110
#define PSP_P2CMSG_INTSTS 0x0114
@@ -54,6 +66,11 @@ struct psp_device {
struct sp_device *sp;
void __iomem *io_regs;
+
+ unsigned int sev_int_rcvd;
+ wait_queue_head_t sev_int_queue;
+ bool has_sev_fops;
+ struct miscdevice sev_misc;
};
#endif /* __PSP_DEV_H */
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 496375d7f6a9..2b334fd853c9 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -512,4 +512,163 @@ struct sev_data_dbg {
u32 len; /* In */
} __packed;
+#if defined(CONFIG_CRYPTO_DEV_SP_PSP)
+
+/**
+ * sev_platform_init - perform SEV INIT command
+ *
+ * @init: sev_data_init structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_init(struct sev_data_init *init, int *error);
+
+/**
+ * sev_platform_shutdown - perform SEV SHUTDOWN command
+ *
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_shutdown(int *error);
+
+/**
+ * sev_platform_status - perform SEV PLATFORM_STATUS command
+ *
+ * @init: sev_data_status structure to be processed
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ */
+int sev_platform_status(struct sev_data_status *status, int *error);
+
+/**
+ * sev_issue_cmd_external_user - issue SEV command by other driver with a file
+ * handle.
+ *
+ * The function can be used by other drivers to issue a SEV command on
+ * behalf by userspace. The caller must pass a valid SEV file descriptor
+ * so that we know that caller has access to SEV device.
+ *
+ * @filep - SEV device file pointer
+ * @cmd - command to issue
+ * @data - command buffer
+ * @error: SEV command return code
+ *
+ * Returns:
+ * 0 if the SEV successfully processed the command
+ * -%ENODEV if the SEV device is not available
+ * -%ENOTSUPP if the SEV does not support SEV
+ * -%ETIMEDOUT if the SEV command timed out
+ * -%EIO if the SEV returned a non-zero return code
+ * -%EINVAL if the SEV file descriptor is not valid
+ */
+int sev_issue_cmd_external_user(struct file *filep, unsigned int id,
+ void *data, int *error);
+
+/**
+ * sev_guest_deactivate - perform SEV DEACTIVATE command
+ *
+ * @deactivate: sev_data_deactivate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_deactivate(struct sev_data_deactivate *data, int *error);
+
+/**
+ * sev_guest_activate - perform SEV ACTIVATE command
+ *
+ * @activate: sev_data_activate structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_activate(struct sev_data_activate *data, int *error);
+
+/**
+ * sev_guest_df_flush - perform SEV DF_FLUSH command
+ *
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_df_flush(int *error);
+
+/**
+ * sev_guest_decommission - perform SEV DECOMMISSION command
+ *
+ * @decommission: sev_data_decommission structure to be processed
+ * @sev_ret: sev command return code
+ *
+ * Returns:
+ * 0 if the sev successfully processed the command
+ * -%ENODEV if the sev device is not available
+ * -%ENOTSUPP if the sev does not support SEV
+ * -%ETIMEDOUT if the sev command timed out
+ * -%EIO if the sev returned a non-zero return code
+ */
+int sev_guest_decommission(struct sev_data_decommission *data, int *error);
+
+#else /* !CONFIG_CRYPTO_DEV_SP_PSP */
+
+static inline int
+sev_platform_status(struct sev_data_status *status, int *error) { return -ENODEV; }
+
+static inline int
+sev_platform_init(struct sev_data_init *init, int *error) { return -ENODEV; }
+
+static inline int sev_platform_shutdown(int *error) { return -ENODEV; }
+
+static inline int
+sev_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] 112+ messages in thread* [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-07 14:20 ` Borislav Petkov
2017-10-11 16:46 ` [Part2 PATCH v5.2 12.1/31] " Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
` (8 subsequent siblings)
9 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
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
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
include/uapi/linux/psp-sev.h | 115 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 115 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..a385bf2b8d2a
--- /dev/null
+++ b/include/uapi/linux/psp-sev.h
@@ -0,0 +1,115 @@
+/*
+ * 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
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u8 owner; /* Out */
+ __u32 config; /* Out */
+ __u8 build; /* Out */
+ __u32 guest_count; /* Out */
+};
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+ __u64 address; /* In */
+ __u32 length; /* In/Out */
+};
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+ __u64 pek_cert_address; /* In */
+ __u32 pek_cert_len; /* In */
+ __u64 oca_cert_address; /* In */
+ __u32 oca_cert_len; /* In */
+};
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+ __u64 pdh_cert_address; /* In */
+ __u32 pdh_cert_len; /* In/Out */
+ __u64 cert_chain_address; /* In */
+ __u32 cert_chain_len; /* In/Out */
+};
+
+/**
+ * struct sev_issue_cmd - SEV ioctl parameters
+ *
+ * @cmd: SEV commands to execute
+ * @opaque: pointer to the command structure
+ * @error: SEV FW return code on failure
+ */
+struct sev_issue_cmd {
+ __u32 cmd; /* In */
+ __u64 data; /* In */
+ __u32 error; /* Out */
+};
+
+#define SEV_IOC_TYPE 'S'
+#define SEV_ISSUE_CMD _IOWR(SEV_IOC_TYPE, 0x0, struct sev_issue_cmd)
+
+#endif /* __PSP_USER_SEV_H */
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
@ 2017-10-07 14:20 ` Borislav Petkov
2017-10-08 21:18 ` Brijesh Singh
2017-10-11 16:46 ` [Part2 PATCH v5.2 12.1/31] " Brijesh Singh
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-07 14:20 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:00PM -0500, 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
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> include/uapi/linux/psp-sev.h | 115 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
> create mode 100644 include/uapi/linux/psp-sev.h
First of all, thanks for splitting the patch - it is much easier to
review this way.
Then, this patch should be 12.1, i.e., the first of the split because otherwise
the previous one - which should be the next - fails building due to
drivers/crypto/ccp/psp-dev.c:26:32: fatal error: uapi/linux/psp-sev.h: No such file or directory
#include <uapi/linux/psp-sev.h>
^
Just swap them in their order.
Also, those SEV commands should be __packed, see below.
With that addressed:
Reviewed-by: Borislav Petkov <bp@suse.de>
---
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
index a385bf2b8d2a..b63e116f18c1 100644
--- a/include/uapi/linux/psp-sev.h
+++ b/include/uapi/linux/psp-sev.h
@@ -53,7 +53,7 @@ struct sev_user_data_status {
__u32 config; /* Out */
__u8 build; /* Out */
__u32 guest_count; /* Out */
-};
+} __packed;
/**
* struct sev_user_data_pek_csr - PEK_CSR command parameters
@@ -64,7 +64,7 @@ struct sev_user_data_status {
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
@@ -79,7 +79,7 @@ struct sev_user_data_pek_cert_import {
__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
@@ -94,7 +94,7 @@ struct sev_user_data_pdh_cert_export {
__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
@@ -107,7 +107,7 @@ 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)
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-07 14:20 ` Borislav Petkov
@ 2017-10-08 21:18 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-08 21:18 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/7/17 9:20 AM, Borislav Petkov wrote:
> On Fri, Oct 06, 2017 at 08:06:00PM -0500, 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
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>> include/uapi/linux/psp-sev.h | 115 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>> create mode 100644 include/uapi/linux/psp-sev.h
> First of all, thanks for splitting the patch - it is much easier to
> review this way.
>
> Then, this patch should be 12.1, i.e., the first of the split because otherwise
> the previous one - which should be the next - fails building due to
>
> drivers/crypto/ccp/psp-dev.c:26:32: fatal error: uapi/linux/psp-sev.h: No such file or directory
> #include <uapi/linux/psp-sev.h>
> ^
> Just swap them in their order.
Ah, yes I will swap the order in next submission. thanks
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.2 12.1/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
2017-10-07 14:20 ` Borislav Petkov
@ 2017-10-11 16:46 ` Brijesh Singh
2017-10-12 13:27 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 16:46 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
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>
---
Make it as the first patch in the series (changed from 12.2/31 -> 12.1/31)
Changes since v5.1:
* add __packed improvement from Boris
The full tree is available at:
repo: https://github.com/codomania/kvm
branch: sev-v5-p2+fixes
include/uapi/linux/psp-sev.h | 115 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 115 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..b63e116f18c1
--- /dev/null
+++ b/include/uapi/linux/psp-sev.h
@@ -0,0 +1,115 @@
+/*
+ * 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
+ * @owner: self-owned or externally owned
+ * @config: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+ __u8 api_major; /* Out */
+ __u8 api_minor; /* Out */
+ __u8 state; /* Out */
+ __u8 owner; /* Out */
+ __u32 config; /* 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] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.1/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-11 16:46 ` [Part2 PATCH v5.2 12.1/31] " Brijesh Singh
@ 2017-10-12 13:27 ` Borislav Petkov
2017-10-12 14:18 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 13:27 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 11:46:05AM -0500, 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>
> ---
> Make it as the first patch in the series (changed from 12.2/31 -> 12.1/31)
>
> Changes since v5.1:
> * add __packed improvement from Boris
...
> +/**
> + * struct sev_user_data_status - PLATFORM_STATUS command parameters
> + *
> + * @major: major API version
> + * @minor: minor API version
> + * @state: platform state
> + * @owner: self-owned or externally owned
> + * @config: platform config flags
> + * @build: firmware build id for API version
> + * @guest_count: number of active guests
> + */
> +struct sev_user_data_status {
> + __u8 api_major; /* Out */
> + __u8 api_minor; /* Out */
> + __u8 state; /* Out */
> + __u8 owner; /* Out */
> + __u32 config; /* Out */
> + __u8 build; /* Out */
> + __u32 guest_count; /* Out */
> +} __packed;
> +
After yesterday's discussion about the sev_data_status layout, that
struct is not needed anymore, right?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.1/31] crypto: ccp: Define SEV userspace ioctl and command id
2017-10-12 13:27 ` Borislav Petkov
@ 2017-10-12 14:18 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 14:18 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/12/2017 08:27 AM, Borislav Petkov wrote:
...
>
>> +/**
>> + * struct sev_user_data_status - PLATFORM_STATUS command parameters
>> + *
>> + * @major: major API version
>> + * @minor: minor API version
>> + * @state: platform state
>> + * @owner: self-owned or externally owned
>> + * @config: platform config flags
>> + * @build: firmware build id for API version
>> + * @guest_count: number of active guests
>> + */
>> +struct sev_user_data_status {
>> + __u8 api_major; /* Out */
>> + __u8 api_minor; /* Out */
>> + __u8 state; /* Out */
>> + __u8 owner; /* Out */
>> + __u32 config; /* Out */
>> + __u8 build; /* Out */
>> + __u32 guest_count; /* Out */
>> +} __packed;
>> +
>
> After yesterday's discussion about the sev_data_status layout, that
> struct is not needed anymore, right?
>
Yes, we no longer need that structure.
-Brijesh
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-11 14:32 ` Borislav Petkov
2017-10-11 16:55 ` [Part2 PATCH v5.2 " Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
` (7 subsequent siblings)
9 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/psp-dev.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e9b776c3acb2..94a08c371bda 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -179,7 +179,34 @@ static int sev_handle_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_CMD_MAX)
+ return -EINVAL;
+
+ switch (input.cmd) {
+
+ case SEV_FACTORY_RESET: {
+ ret = sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
+ break;
+ }
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
+ ret = -EFAULT;
+
+ return ret;
}
const struct file_operations sev_fops = {
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
@ 2017-10-11 14:32 ` Borislav Petkov
2017-10-11 16:55 ` [Part2 PATCH v5.2 " Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 14:32 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:01PM -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
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> drivers/crypto/ccp/psp-dev.c | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
Some fixes ontop, like, for example, if you hit the default: label of
the switch due to input.cmd being one of the ones in the holes in enum
sev_cmd, you don't need to copy_to_user() in the end.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d3a50f1f737e..ed5a7404b5a5 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -192,19 +192,19 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
return -EINVAL;
switch (input.cmd) {
-
- case SEV_FACTORY_RESET: {
- ret = sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
+ case SEV_FACTORY_RESET:
+ ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
break;
- }
+
default:
ret = -EINVAL;
- break;
+ goto out;
}
if (copy_to_user(argp, &input, sizeof(struct sev_issue_cmd)))
ret = -EFAULT;
+out:
return ret;
}
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5.2 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
2017-10-11 14:32 ` Borislav Petkov
@ 2017-10-11 16:55 ` Brijesh Singh
2017-10-12 14:13 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 16:55 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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>
---
Changes since v5.1:
* rename sev_handle_cmd -> sev_do_cmd (from Boris)
* skip copy_to_user when invalid cmd id is passed (from Boris)
* use SEV_MAX instead of SEV_CMD_MAX to check for invalid command
drivers/crypto/ccp/psp-dev.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 175cb3c3b8ef..a9c885a39910 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -179,7 +179,34 @@ 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] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command
2017-10-11 16:55 ` [Part2 PATCH v5.2 " Brijesh Singh
@ 2017-10-12 14:13 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 14:13 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 11:55:21AM -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>
> ---
>
> Changes since v5.1:
> * rename sev_handle_cmd -> sev_do_cmd (from Boris)
> * skip copy_to_user when invalid cmd id is passed (from Boris)
> * use SEV_MAX instead of SEV_CMD_MAX to check for invalid command
>
> drivers/crypto/ccp/psp-dev.c | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 175cb3c3b8ef..a9c885a39910 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -179,7 +179,34 @@ 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;
> + }
Those curly braces are still here. Just use my diff I sent you by saving
the mail to a file and doing
$ patch -p1 --dry-run -i /tmp/boris.mail
ontop of this patch. If it applies ok, remove the --dry-run.
Then you can do changes ontop. This way you won't miss changes I've sent
you.
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.2/31] crypto: ccp: Define SEV userspace ioctl and command id Brijesh Singh
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.3/31] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-11 17:01 ` [Part2 PATCH v5.2 " Brijesh Singh
2017-10-11 17:02 ` [Part2 PATCH v5.1 " Borislav Petkov
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
` (6 subsequent siblings)
9 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
drivers/crypto/ccp/psp-dev.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 94a08c371bda..d68303a06464 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -177,6 +177,36 @@ static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
return ret;
}
+static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_status out;
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
+ if (ret)
+ goto e_free;
+
+ out.api_major = data->api_major;
+ out.api_minor = data->api_minor;
+ out.state = data->state;
+ out.owner = data->owner;
+ out.config = data->config;
+ out.build = data->build;
+ out.guest_count = data->guest_count;
+ if (copy_to_user((void __user *)(uintptr_t) argp->data,
+ &out, sizeof(struct sev_user_data_status)))
+ 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;
@@ -198,6 +228,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
break;
}
+ case SEV_PLATFORM_STATUS: {
+ ret = sev_ioctl_platform_status(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5.2 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
@ 2017-10-11 17:01 ` Brijesh Singh
2017-10-11 17:02 ` [Part2 PATCH v5.1 " Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 17:01 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
Changes since v5.1:
* rename sev_handle_cmd -> sev_do_cmd
drivers/crypto/ccp/psp-dev.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index a9c885a39910..1f4925cf9ae5 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -177,6 +177,36 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
return ret;
}
+static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_status out;
+ struct sev_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;
+
+ out.api_major = data->api_major;
+ out.api_minor = data->api_minor;
+ out.state = data->state;
+ out.owner = data->owner;
+ out.config = data->config;
+ out.build = data->build;
+ out.guest_count = data->guest_count;
+ if (copy_to_user((void __user *)(uintptr_t) argp->data,
+ &out, sizeof(struct sev_user_data_status)))
+ 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;
@@ -198,6 +228,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
break;
}
+ case SEV_PLATFORM_STATUS: {
+ ret = sev_ioctl_platform_status(&input);
+ break;
+ }
default:
ret = -EINVAL;
goto out;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
2017-10-11 17:01 ` [Part2 PATCH v5.2 " Brijesh Singh
@ 2017-10-11 17:02 ` Borislav Petkov
2017-10-11 19:49 ` Brijesh Singh
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 17:02 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:02PM -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
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> drivers/crypto/ccp/psp-dev.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
...
> @@ -198,6 +228,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> ret = sev_handle_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
> break;
> }
> + case SEV_PLATFORM_STATUS: {
> + ret = sev_ioctl_platform_status(&input);
> + break;
> + }
What's with the curly brackets around the case: statements?
Anyway, here are some more improvements:
* you can get rid of the struct copying into out and the bitfields by
doing something like this:
ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
if (ret)
goto e_free;
/* Clear out reserved fields: */
data->owner &= BIT(0);
data->config &= BIT(0);
I'm not sure those are the ones you need to clear but you get
the idea - you simply poke holes in the reserved fields before
copying to userspace. If you need a more sophisticated mask, use
GENMASK/GENMASK_ULL.
And then you don't need struct sev_user_data_status and
simply remove the bitfields too.
* Also, a function should have a verb in the name, thus
sev_ioctl_do_platform_status().
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d668045956cb..1479db533da0 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -176,9 +176,8 @@ static int sev_do_cmd(int cmd, void *data, int *psp_ret)
return ret;
}
-static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
+static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
{
- struct sev_user_data_status out;
struct sev_data_status *data;
int ret;
@@ -186,19 +185,15 @@ static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
if (!data)
return -ENOMEM;
- ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
if (ret)
goto e_free;
- out.api_major = data->api_major;
- out.api_minor = data->api_minor;
- out.state = data->state;
- out.owner = data->owner;
- out.config = data->config;
- out.build = data->build;
- out.guest_count = data->guest_count;
- if (copy_to_user((void __user *)(uintptr_t) argp->data,
- &out, sizeof(struct sev_user_data_status)))
+ /* Clear out reserved fields: */
+ data->owner &= BIT(0);
+ data->config &= BIT(0);
+
+ if (copy_to_user((void __user *)argp->data, data, sizeof(*data)))
ret = -EFAULT;
e_free:
@@ -226,10 +221,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_do_cmd(SEV_CMD_FACTORY_RESET, 0, &input.error);
break;
- case SEV_PLATFORM_STATUS: {
- ret = sev_ioctl_platform_status(&input);
+ case SEV_PLATFORM_STATUS:
+ ret = sev_ioctl_do_platform_status(&input);
break;
- }
+
default:
ret = -EINVAL;
goto out;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 10b843cce75f..223942ba3e7e 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -144,11 +144,9 @@ struct sev_data_status {
u8 api_major; /* Out */
u8 api_minor; /* Out */
u8 state; /* Out */
- u8 owner : 1; /* Out */
- u8 reserved1 : 7;
- u32 config : 1; /* Out */
- u32 reserved2 : 23;
- u32 build : 8; /* Out */
+ u8 owner; /* Out */
+ u32 config; /* Out */
+ u32 build; /* Out */
u32 guest_count; /* Out */
} __packed;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 17:02 ` [Part2 PATCH v5.1 " Borislav Petkov
@ 2017-10-11 19:49 ` Brijesh Singh
2017-10-11 20:04 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 19: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/11/2017 12:02 PM, Borislav Petkov wrote:
...
>
> What's with the curly brackets around the case: statements?
>
I will remove the curly braces.
> Anyway, here are some more improvements:
>
> * you can get rid of the struct copying into out and the bitfields by
> doing something like this:
>
> ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, &argp->error);
> if (ret)
> goto e_free;
>
> /* Clear out reserved fields: */
> data->owner &= BIT(0);
> data->config &= BIT(0);
>
> I'm not sure those are the ones you need to clear but you get
> the idea - you simply poke holes in the reserved fields before
> copying to userspace. If you need a more sophisticated mask, use
> GENMASK/GENMASK_ULL.
>
If we decide to go with this approach then we need use GENMASK (see below).
...
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -144,11 +144,9 @@ struct sev_data_status {
Since the structure is shared with firmware hence I was trying to match
it with the spec.
> u8 api_major; /* Out */
> u8 api_minor; /* Out */
> u8 state; /* Out */
> - u8 owner : 1; /* Out */
> - u8 reserved1 : 7;
> - u32 config : 1; /* Out */
> - u32 reserved2 : 23;
> - u32 build : 8; /* Out */
> + u8 owner; /* Out */
This is OK for now. But in future if FW steals another bit from
reserved1 field to expose a new flag then 'owner' name will no longer be
valid. If you don't to use bit field then we have to use some generic
name instead of naming the field as 'owner'. Please note that its not
just userspace, KVM driver also uses the same fields and it may also
need to know which bit position to use.
> + u32 config; /* Out */
> + u32 build; /* Out */
This is a tricky one. The 32-bit are packed as:
BIT0 - config.es
BIT1-23: reserved
BIT24-31: build
Now, if we really don't want to use bit field then we have to declare
them as:
u8 config[3];
u8 build;
I would prefer to keep the structure as is. I am OK with changing the
userspace sev_user_data_status to match with FW's sev_data_status to
avoid the coying from FW structure to userspace structure.
> u32 guest_count; /* Out */
> } __packed;
>
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 19:49 ` Brijesh Singh
@ 2017-10-11 20:04 ` Borislav Petkov
2017-10-11 20:10 ` Borislav Petkov
2017-10-11 20:10 ` Brijesh Singh
0 siblings, 2 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 20:04 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 02:49:55PM -0500, Brijesh Singh wrote:
> This is OK for now. But in future if FW steals another bit from reserved1
> field to expose a new flag then 'owner' name will no longer be valid. If you
> don't to use bit field then we have to use some generic name instead of
> naming the field as 'owner'. Please note that its not just userspace, KVM
> driver also uses the same fields and it may also need to know which bit
> position to use.
So what is this field called in the spec?
> This is a tricky one. The 32-bit are packed as:
>
> BIT0 - config.es
> BIT1-23: reserved
> BIT24-31: build
Is that what the firmware gives?
Then it is easy:
<firmware_field_name> &= GENMASK(23, 1);
and then userspace can pick apart bit 0 and bit24-31.
Just use one raw struct which the firmware gives you and the rest is
done by the sw. Like clearing reserved fields before copying to user.
You don't want to be updating that struct layout later: think of old
qemu with new kernel and all those different configurations.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:04 ` Borislav Petkov
@ 2017-10-11 20:10 ` Borislav Petkov
2017-10-11 20:10 ` Brijesh Singh
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 20:10 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 10:04:44PM +0200, Borislav Petkov wrote:
> Then it is easy:
>
> <firmware_field_name> &= GENMASK(23, 1);
[1:23] range cleared, of course:
<firmware_field_name> &= ~GENMASK(23, 1);
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:04 ` Borislav Petkov
2017-10-11 20:10 ` Borislav Petkov
@ 2017-10-11 20:10 ` Brijesh Singh
2017-10-11 20:28 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 20:10 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/11/2017 03:04 PM, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 02:49:55PM -0500, Brijesh Singh wrote:
>> This is OK for now. But in future if FW steals another bit from reserved1
>> field to expose a new flag then 'owner' name will no longer be valid. If you
>> don't to use bit field then we have to use some generic name instead of
>> naming the field as 'owner'. Please note that its not just userspace, KVM
>> driver also uses the same fields and it may also need to know which bit
>> position to use.
>
> So what is this field called in the spec?
>
See Section 5.5.2 [1]
[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
The bit0 is named as 'owner' and bits 7:1 is left blank (no name is given).
>> This is a tricky one. The 32-bit are packed as:
>>
>> BIT0 - config.es
>> BIT1-23: reserved
>> BIT24-31: build
>
> Is that what the firmware gives?
>
Yes
> Then it is easy:
>
> <firmware_field_name> &= GENMASK(23, 1);
>
> and then userspace can pick apart bit 0 and bit24-31.
>
The bit0 is named as config.es and bit1-23 is left blank and bit31-24 is
named as build.
The current 'struct sev_data_status' matches with the firmware names and
the bit fields. Only thing I did was the fields with no name is called
as "reservedX"
> Just use one raw struct which the firmware gives you and the rest is
> done by the sw. Like clearing reserved fields before copying to user.
>
> You don't want to be updating that struct layout later: think of old
> qemu with new kernel and all those different configurations.
>
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:10 ` Brijesh Singh
@ 2017-10-11 20:28 ` Borislav Petkov
2017-10-11 20:45 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 20:28 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
> The current 'struct sev_data_status' matches with the firmware names and the
> bit fields. Only thing I did was the fields with no name is called as
> "reservedX"
Ok, I see it. So what you actually wanna do is:
struct sev_data_status {
u8 api_major; /* Out */
u8 api_minor; /* Out */
u8 state; /* Out */
u8 flags; /* Out */
u32 config; /* Out */
u32 guest_count; /* Out */
} __packed;
as this is exactly what the firwmare gives you. Theoretically, you
could've also done:
struct sev_data_status {
u64 first_qword;
u32 second_dword;
};
but you have the fields mostly defined already and that would be too
confusing.
What I mean is, once you've gotten the command buffer, then you can pick
fields apart in software.
owner = status.flags & 1;
config_es = status.config & 1;
build = (status.config >> 24) & 0xff;
This way, if new fields get added, you don't have to change the struct
definitions - *especially* if they're visible to userspace - and users
of that struct can be extended to understand the new fields.
And before you copy the struct to userspace, you can simply clear out
the reserved fields as nothing should rely on them having a particular
value, because, well, they're reserved, doh.
Makes sense?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:28 ` Borislav Petkov
@ 2017-10-11 20:45 ` Brijesh Singh
2017-10-11 20:53 ` Brijesh Singh
2017-10-11 20:54 ` Borislav Petkov
0 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 20:45 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/11/2017 03:28 PM, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
>> The current 'struct sev_data_status' matches with the firmware names and the
>> bit fields. Only thing I did was the fields with no name is called as
>> "reservedX"
>
> Ok, I see it. So what you actually wanna do is:
>
> struct sev_data_status {
> u8 api_major; /* Out */
> u8 api_minor; /* Out */
> u8 state; /* Out */
> u8 flags; /* Out */
> u32 config; /* Out */
> u32 guest_count; /* Out */
> } __packed;
>
OK, if userspace is going to pick bits apart then how about this:
struct sev_data_status {
u8 api_major; /* Out */
u8 api_minor; /* Out */
u8 state; /* Out */
u32 flags; /* Out */
u8 build; /* Out */
u32 guest_count; /* Out */
} __packed;
>
> Makes sense?
>
Please let me know if you are okay with my above structure.
-Brijesh
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:45 ` Brijesh Singh
@ 2017-10-11 20:53 ` Brijesh Singh
2017-10-11 20:54 ` Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 20:53 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/11/2017 03:45 PM, Brijesh Singh wrote:
>
>
> On 10/11/2017 03:28 PM, Borislav Petkov wrote:
>> On Wed, Oct 11, 2017 at 03:10:49PM -0500, Brijesh Singh wrote:
>>> The current 'struct sev_data_status' matches with the firmware names
>>> and the
>>> bit fields. Only thing I did was the fields with no name is called as
>>> "reservedX"
>>
>> Ok, I see it. So what you actually wanna do is:
>>
>> struct sev_data_status {
>> u8 api_major; /* Out */
>> u8 api_minor; /* Out */
>> u8 state; /* Out */
>> u8 flags; /* Out */
>> u32 config; /* Out */
>> u32 guest_count; /* Out */
>> } __packed;
>>
>
> OK, if userspace is going to pick bits apart then how about this:
>
> struct sev_data_status {
> u8 api_major; /* Out */
> u8 api_minor; /* Out */
> u8 state; /* Out */
> u32 flags; /* Out */
> u8 build; /* Out */
> u32 guest_count; /* Out */
> } __packed;
>
BTW, I kept the build name because KVM driver prints some debug
information like this:
pr_info_once("SEV: api_major %d api_minor %d build %d\n",
status->api_major, status->api_minor, status->build);
Of course, I can modify it to access bit field if we decide to go with
your recommended structure - thanks
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command
2017-10-11 20:45 ` Brijesh Singh
2017-10-11 20:53 ` Brijesh Singh
@ 2017-10-11 20:54 ` Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 20:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 03:45:00PM -0500, Brijesh Singh wrote:
> OK, if userspace is going to pick bits apart then how about this:
>
> struct sev_data_status {
> u8 api_major; /* Out */
> u8 api_minor; /* Out */
> u8 state; /* Out */
> u32 flags; /* Out */
> u8 build; /* Out */
I guess. Except the spec marks those as 31:24 and belonging to the dword
starting at offset 4 and you've made "build" a separate u8 and the dword
starts at offset 3. I mean, not a big deal, I think you can change the
spec for a change :-)
Because it looks like the 4 bytes starting at offset 3 really are meant
for miscellaneous bits. And then CONFIG.ES could've been bit 1 of the
byte at offset 3. Oh well...
> Please let me know if you are okay with my above structure.
But yeah, in the end of the day it probably doesn't matter a whole lot.
The spec just counts those in 32-bit quantities.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (2 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.4/31] crypto: ccp: Implement SEV_PLATFORM_STATUS " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-12 18:28 ` Borislav Petkov
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
` (5 subsequent siblings)
9 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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 | 68 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d68303a06464..03d7bd03ad58 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -207,6 +207,70 @@ static int sev_ioctl_platform_status(struct sev_issue_cmd *argp)
return ret;
}
+static int sev_platform_get_state(int *state, int *error)
+{
+ struct sev_data_status *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+ if (!ret)
+ *state = data->state;
+
+ kfree(data);
+ return ret;
+}
+
+static int sev_firmware_init(int *error)
+{
+ struct sev_data_init *data;
+ int rc;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ rc = sev_handle_cmd(SEV_CMD_INIT, data, error);
+
+ kfree(data);
+ return rc;
+}
+
+static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
+{
+ int do_shutdown = 0;
+ int ret, state;
+
+ /*
+ * PEK_GEN command can be issued only when firmware is in INIT state.
+ * If firmware is in UNINIT state then we transition it in INIT state
+ * and issue the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_WORKING) {
+ return -EBUSY;
+ } else if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -232,6 +296,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_platform_status(&input);
break;
}
+ case SEV_PEK_GEN: {
+ ret = sev_ioctl_pek_gen(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
@ 2017-10-12 18:28 ` Borislav Petkov
2017-10-12 20:11 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 18:28 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:03PM -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 | 68 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
Just small fixups. Worth noting is this:
if (do_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
I think we want to return the result of the *last* command
executed, which, in the do_shutdown=1 case is SEV_CMD_SHUTDOWN, not
SEV_CMD_PEK_GEN.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d02f48e356e8..31045ea7e798 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -211,7 +211,7 @@ static int sev_platform_get_state(int *state, int *error)
if (!data)
return -ENOMEM;
- ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+ ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
if (!ret)
*state = data->state;
@@ -228,7 +228,7 @@ static int sev_firmware_init(int *error)
if (!data)
return -ENOMEM;
- rc = sev_handle_cmd(SEV_CMD_INIT, data, error);
+ rc = sev_do_cmd(SEV_CMD_INIT, data, error);
kfree(data);
return rc;
@@ -240,8 +240,8 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
int ret, state;
/*
- * PEK_GEN command can be issued only when firmware is in INIT state.
- * If firmware is in UNINIT state then we transition it in INIT state
+ * The PEK_GEN command can be issued only when the firmware is in INIT
+ * state. If it is in UNINIT state then we transition it in INIT state
* and issue the command.
*/
ret = sev_platform_get_state(&state, &argp->error);
@@ -258,10 +258,10 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
do_shutdown = 1;
}
- ret = sev_handle_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
if (do_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
return ret;
}
@@ -291,10 +291,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_do_platform_status(&input);
break;
- case SEV_PEK_GEN: {
+ case SEV_PEK_GEN:
ret = sev_ioctl_pek_gen(&input);
break;
- }
+
default:
ret = -EINVAL;
goto out;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command
2017-10-12 18:28 ` Borislav Petkov
@ 2017-10-12 20:11 ` Brijesh Singh
2017-10-12 20:21 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 20:11 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/12/17 1:28 PM, Borislav Petkov wrote:
> On Fri, Oct 06, 2017 at 08:06:03PM -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 | 68 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
> Just small fixups. Worth noting is this:
>
> if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>
> I think we want to return the result of the *last* command
> executed, which, in the do_shutdown=1 case is SEV_CMD_SHUTDOWN, not
> SEV_CMD_PEK_GEN.
Lets consider this scenario
1- platform is in uninit state, we transition it to INIT
2- PEK_GEN command failed
3- since we have transitioned the platform in INIT state hence we must
call the shutdown otherwise we will leave the system in wrong state. The
shutdown command will most probably succeed and we will look the ret value
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index d02f48e356e8..31045ea7e798 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -211,7 +211,7 @@ static int sev_platform_get_state(int *state, int *error)
> if (!data)
> return -ENOMEM;
>
> - ret = sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
> + ret = sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
> if (!ret)
> *state = data->state;
>
> @@ -228,7 +228,7 @@ static int sev_firmware_init(int *error)
> if (!data)
> return -ENOMEM;
>
> - rc = sev_handle_cmd(SEV_CMD_INIT, data, error);
> + rc = sev_do_cmd(SEV_CMD_INIT, data, error);
>
> kfree(data);
> return rc;
> @@ -240,8 +240,8 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
> int ret, state;
>
> /*
> - * PEK_GEN command can be issued only when firmware is in INIT state.
> - * If firmware is in UNINIT state then we transition it in INIT state
> + * The PEK_GEN command can be issued only when the firmware is in INIT
> + * state. If it is in UNINIT state then we transition it in INIT state
> * and issue the command.
> */
> ret = sev_platform_get_state(&state, &argp->error);
> @@ -258,10 +258,10 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
> do_shutdown = 1;
> }
>
> - ret = sev_handle_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
> + ret = sev_do_cmd(SEV_CMD_PEK_GEN, 0, &argp->error);
>
> if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>
> return ret;
> }
> @@ -291,10 +291,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> ret = sev_ioctl_do_platform_status(&input);
> break;
>
> - case SEV_PEK_GEN: {
> + case SEV_PEK_GEN:
> ret = sev_ioctl_pek_gen(&input);
> break;
> - }
> +
> default:
> ret = -EINVAL;
> goto out;
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command
2017-10-12 20:11 ` Brijesh Singh
@ 2017-10-12 20:21 ` Borislav Petkov
2017-10-12 20:34 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 20: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 Thu, Oct 12, 2017 at 03:11:07PM -0500, Brijesh Singh wrote:
> Lets consider this scenario
> 1- platform is in uninit state, we transition it to INIT
> 2- PEK_GEN command failed
> 3- since we have transitioned the platform in INIT state hence we must
> call the shutdown otherwise we will leave the system in wrong state. The
> shutdown command will most probably succeed and we will look the ret value
Sure but what do you do if the main command, i.e., PEK_GEN succeeds but
the shutdown command fails?
You probably should carve out the whole shutdown order in separate
functions. I mean, the sequences do repeat in a couple of functions so
you could do:
ioctl:
case <CMD>:
init_platform()
do_main_cmd()
shutdown_platform()
break;
and this way you have everything nicely separated and retvals properly
tracked...
Hmmm?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN ioctl command
2017-10-12 20:21 ` Borislav Petkov
@ 2017-10-12 20:34 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 20:34 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/12/17 3:21 PM, Borislav Petkov wrote:
> On Thu, Oct 12, 2017 at 03:11:07PM -0500, Brijesh Singh wrote:
>> Lets consider this scenario
>> 1- platform is in uninit state, we transition it to INIT
>> 2- PEK_GEN command failed
>> 3- since we have transitioned the platform in INIT state hence we must
>> call the shutdown otherwise we will leave the system in wrong state. The
>> shutdown command will most probably succeed and we will look the ret value
> Sure but what do you do if the main command, i.e., PEK_GEN succeeds but
> the shutdown command fails?
>
> You probably should carve out the whole shutdown order in separate
> functions. I mean, the sequences do repeat in a couple of functions so
> you could do:
>
> ioctl:
>
> case <CMD>:
>
> init_platform()
> do_main_cmd()
> shutdown_platform()
> break;
>
> and this way you have everything nicely separated and retvals properly
> tracked...
>
> Hmmm?
Some commands are allowed in INIT and WORKING, some in UINIT only, some
WORKING, and others in all the state. We need to follow the platform
state machine. I will see what I can do. thanks
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (3 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.5/31] crypto: ccp: Implement SEV_PEK_GEN " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-12 18:48 ` Borislav Petkov
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
` (4 subsequent siblings)
9 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The SEV_PDH_GEN command is used to re-generate the Platform
Diffie-Hellman (PDH) key. The command is defined in SEV spec section
5.9.
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 | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 03d7bd03ad58..28efb7a9245a 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -271,6 +271,34 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
return ret;
}
+static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
+{
+ int ret, state, do_shutdown = 0;
+
+ /*
+ * PDH_GEN command can be issued when platform is in INIT or WORKING
+ * state. If we are in UNINIT state then transition in INIT state
+ * before issuing the command.
+ */
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ return ret;
+
+ if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ return ret;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_GEN, 0, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+ return ret;
+}
+
static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -300,6 +328,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pek_gen(&input);
break;
}
+ case SEV_PDH_GEN: {
+ ret = sev_ioctl_pdh_gen(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
@ 2017-10-12 18:48 ` Borislav Petkov
2017-10-12 20:21 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 18:48 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:04PM -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.9.
>
> 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 | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 03d7bd03ad58..28efb7a9245a 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -271,6 +271,34 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
> return ret;
> }
>
> +static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
> +{
> + int ret, state, do_shutdown = 0;
> +
> + /*
> + * PDH_GEN command can be issued when platform is in INIT or WORKING
> + * state. If we are in UNINIT state then transition in INIT state
> + * before issuing the command.
> + */
> + ret = sev_platform_get_state(&state, &argp->error);
> + if (ret)
> + return ret;
> +
Why isn't this function doing:
if (state == SEV_STATE_WORKING) {
return -EBUSY;
like the PEK_GEN one?
Because if so, you can convert it and the PEK_GEN one into a single
function doing the work and wrappers handing in the command to avoid the
code duplication.
> + if (state == SEV_STATE_UNINIT) {
> + ret = sev_firmware_init(&argp->error);
> + if (ret)
> + return ret;
> + do_shutdown = 1;
> + }
> +
> + ret = sev_handle_cmd(SEV_CMD_PDH_GEN, 0, &argp->error);
> +
> + if (do_shutdown)
> + sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> +
> + return ret;
> +}
> +
> static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> {
> void __user *argp = (void __user *)arg;
> @@ -300,6 +328,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> ret = sev_ioctl_pek_gen(&input);
> break;
> }
> + case SEV_PDH_GEN: {
> + ret = sev_ioctl_pdh_gen(&input);
> + break;
> + }
And those curly braces can go, as before.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command
2017-10-12 18:48 ` Borislav Petkov
@ 2017-10-12 20:21 ` Brijesh Singh
2017-10-12 20:23 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 20:21 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/12/17 1:48 PM, Borislav Petkov wrote:
...
> On Fri, Oct 06, 2017 at 08:06:04PM -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.9.
>>
>> 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 | 32 ++++++++++++++++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index 03d7bd03ad58..28efb7a9245a 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -271,6 +271,34 @@ static int sev_ioctl_pek_gen(struct sev_issue_cmd *argp)
>> return ret;
>> }
>>
>> +static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
>> +{
>> + int ret, state, do_shutdown = 0;
>> +
>> + /*
>> + * PDH_GEN command can be issued when platform is in INIT or WORKING
>> + * state. If we are in UNINIT state then transition in INIT state
>> + * before issuing the command.
>> + */
>> + ret = sev_platform_get_state(&state, &argp->error);
>> + if (ret)
>> + return ret;
>> +
> Why isn't this function doing:
>
> if (state == SEV_STATE_WORKING) {
> return -EBUSY;
>
> like the PEK_GEN one?
We need to follow the platform state machine logic defined in SEV spec
section 5.1.2. The PEK_GEN can not be issued when platform is in WORKING
state because the command actually re-generate the identity of the
platform itself (in other words re-generate the Platform Endorsement
Key). Whereas, the PDH_GEN command is used for re-generating Platform
Diffie-Hellman Key which can be changed while the guest is running.
> Because if so, you can convert it and the PEK_GEN one into a single
> function doing the work and wrappers handing in the command to avoid the
> code duplication.
>
>> + if (state == SEV_STATE_UNINIT) {
>> + ret = sev_firmware_init(&argp->error);
>> + if (ret)
>> + return ret;
>> + do_shutdown = 1;
>> + }
>> +
>> + ret = sev_handle_cmd(SEV_CMD_PDH_GEN, 0, &argp->error);
>> +
>> + if (do_shutdown)
>> + sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +
>> + return ret;
>> +}
>> +
>> static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>> {
>> void __user *argp = (void __user *)arg;
>> @@ -300,6 +328,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>> ret = sev_ioctl_pek_gen(&input);
>> break;
>> }
>> + case SEV_PDH_GEN: {
>> + ret = sev_ioctl_pdh_gen(&input);
>> + break;
>> + }
> And those curly braces can go, as before.
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN ioctl command
2017-10-12 20:21 ` Brijesh Singh
@ 2017-10-12 20:23 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 20:23 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Thu, Oct 12, 2017 at 03:21:04PM -0500, Brijesh Singh wrote:
> We need to follow the platform state machine logic defined in SEV spec
> section 5.1.2. The PEK_GEN can not be issued when platform is in WORKING
> state because the command actually re-generate the identity of the
> platform itself (in other words re-generate the Platform Endorsement
> Key). Whereas, the PDH_GEN command is used for re-generating Platform
> Diffie-Hellman Key which can be changed while the guest is running.
I see.
So the proposition to carve out and split the platform *init commands
might come in handy here too...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (4 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.6/31] crypto: ccp: Implement SEV_PDH_GEN " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-12 19:53 ` Borislav Petkov
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
` (3 subsequent siblings)
9 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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 | 85 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 28efb7a9245a..8038ca7aef03 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -299,6 +299,87 @@ static int sev_ioctl_pdh_gen(struct sev_issue_cmd *argp)
return ret;
}
+static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_csr input;
+ struct sev_data_pek_csr *data;
+ int do_shutdown = 0;
+ int ret, state;
+ void *blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pek_csr)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* allocate a temporary physical contigous buffer to store the CSR blob */
+ blob = NULL;
+ if (input.address) {
+ 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;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_blob;
+
+ /*
+ * PEK_CERT command can be issued only when we are in INIT state.
+ * if current state is WORKING then reject it, if state is UNINIT
+ * then transition the platform to INIT state before issuing the
+ * command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_blob;
+ } else if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_blob;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+
+ input.length = data->len;
+
+ /* copy blob to userspace */
+ if (blob &&
+ copy_to_user((void __user *)(uintptr_t)input.address,
+ blob, input.length)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pek_csr)))
+ ret = -EFAULT;
+
+e_shutdown:
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+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;
@@ -332,6 +413,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pdh_gen(&input);
break;
}
+ case SEV_PEK_CSR: {
+ ret = sev_ioctl_pek_csr(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
@ 2017-10-12 19:53 ` Borislav Petkov
2017-10-13 2:24 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 19:53 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:05PM -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 | 85 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
Ok, a couple of things here:
* Move the checks first and the allocations second so that you allocate
memory only after all checks have been passed and you don't allocate
pointlessly.
* That:
if (state == SEV_STATE_WORKING) {
ret = -EBUSY;
goto e_free_blob;
} else if (state == SEV_STATE_UNINIT) {
ret = sev_firmware_init(&argp->error);
if (ret)
goto e_free_blob;
do_shutdown = 1;
}
is a repeating pattern. Perhaps it should be called
sev_firmware_reinit() and called by other functions.
* The rest is simplifications and streamlining.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e3ee68afd068..d41f5448a25b 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
int ret, state;
void *blob;
- if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
- sizeof(struct sev_user_data_pek_csr)))
+ if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
+ return -EFAULT;
+
+ if (!input.address)
+ return -EINVAL;
+
+ /* 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)
return -EFAULT;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
- /* allocate a temporary physical contigous buffer to store the CSR blob */
- blob = NULL;
- if (input.address) {
- 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;
+ blob = kmalloc(input.length, GFP_KERNEL);
+ if (!blob) {
+ ret = -ENOMEM;
+ goto e_free;
}
+ data->address = __psp_pa(blob);
+ data->len = input.length;
+
ret = sev_platform_get_state(&state, &argp->error);
if (ret)
goto e_free_blob;
@@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
do_shutdown = 1;
}
- ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
input.length = data->len;
/* copy blob to userspace */
- if (blob &&
- copy_to_user((void __user *)(uintptr_t)input.address,
- blob, input.length)) {
+ if (copy_to_user((void __user *)input.address, blob, input.length)) {
ret = -EFAULT;
goto e_shutdown;
}
- if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
- sizeof(struct sev_user_data_pek_csr)))
+ if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
ret = -EFAULT;
e_shutdown:
if (do_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
e_free_blob:
kfree(blob);
e_free:
@@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pdh_gen(&input);
break;
- case SEV_PEK_CSR: {
+ case SEV_PEK_CSR:
ret = sev_ioctl_pek_csr(&input);
break;
- }
+
default:
ret = -EINVAL;
goto out;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-12 19:53 ` Borislav Petkov
@ 2017-10-13 2:24 ` Brijesh Singh
2017-10-13 4:13 ` Brijesh Singh
2017-10-13 9:14 ` Borislav Petkov
0 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-13 2:24 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/12/17 2:53 PM, Borislav Petkov wrote:
...
> Ok, a couple of things here:
>
> * Move the checks first and the allocations second so that you allocate
> memory only after all checks have been passed and you don't allocate
> pointlessly.
I assume you mean performing the SEV state check before allocating the
memory for the CSR blob, right ? In my patches, I typically perform all
the SW specific checks and allocation before invoking the HW routines.
Handling the PSP commands will take longer compare to kmalloc() or
access_ok() etc. If its not a big deal then I would prefer to keep that
way.
>
> * That:
>
> if (state == SEV_STATE_WORKING) {
> ret = -EBUSY;
> goto e_free_blob;
> } else if (state == SEV_STATE_UNINIT) {
> ret = sev_firmware_init(&argp->error);
> if (ret)
> goto e_free_blob;
> do_shutdown = 1;
> }
>
> is a repeating pattern. Perhaps it should be called
> sev_firmware_reinit() and called by other functions.
> * The rest is simplifications and streamlining.
>
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index e3ee68afd068..d41f5448a25b 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
> int ret, state;
> void *blob;
>
> - if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
> - sizeof(struct sev_user_data_pek_csr)))
> + if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> + return -EFAULT;
> +
> + if (!input.address)
> + return -EINVAL;
> +
> + /* 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)
> return -EFAULT;
>
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
>
> - /* allocate a temporary physical contigous buffer to store the CSR blob */
> - blob = NULL;
> - if (input.address) {
> - 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;
> + blob = kmalloc(input.length, GFP_KERNEL);
> + if (!blob) {
> + ret = -ENOMEM;
> + goto e_free;
> }
>
> + data->address = __psp_pa(blob);
> + data->len = input.length;
> +
> ret = sev_platform_get_state(&state, &argp->error);
> if (ret)
> goto e_free_blob;
> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
> do_shutdown = 1;
> }
>
> - ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
> + ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
>
> input.length = data->len;
>
> /* copy blob to userspace */
> - if (blob &&
> - copy_to_user((void __user *)(uintptr_t)input.address,
> - blob, input.length)) {
> + if (copy_to_user((void __user *)input.address, blob, input.length)) {
> ret = -EFAULT;
> goto e_shutdown;
> }
>
> - if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
> - sizeof(struct sev_user_data_pek_csr)))
> + if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
> ret = -EFAULT;
>
> e_shutdown:
> if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> +
> e_free_blob:
> kfree(blob);
> e_free:
> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> ret = sev_ioctl_pdh_gen(&input);
> break;
>
> - case SEV_PEK_CSR: {
> + case SEV_PEK_CSR:
> ret = sev_ioctl_pek_csr(&input);
> break;
> - }
> +
> default:
> ret = -EINVAL;
> goto out;
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-13 2:24 ` Brijesh Singh
@ 2017-10-13 4:13 ` Brijesh Singh
2017-10-13 10:20 ` Borislav Petkov
2017-10-13 9:14 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-13 4:13 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/12/17 9:24 PM, Brijesh Singh wrote:
>
> On 10/12/17 2:53 PM, Borislav Petkov wrote:
> ...
>
>> Ok, a couple of things here:
>>
>> * Move the checks first and the allocations second so that you allocate
>> memory only after all checks have been passed and you don't allocate
>> pointlessly.
>
> I assume you mean performing the SEV state check before allocating the
> memory for the CSR blob, right ? In my patches, I typically perform all
> the SW specific checks and allocation before invoking the HW routines.
> Handling the PSP commands will take longer compare to kmalloc() or
> access_ok() etc. If its not a big deal then I would prefer to keep that
> way.
>
>
>> * That:
>>
>> if (state == SEV_STATE_WORKING) {
>> ret = -EBUSY;
>> goto e_free_blob;
>> } else if (state == SEV_STATE_UNINIT) {
>> ret = sev_firmware_init(&argp->error);
>> if (ret)
>> goto e_free_blob;
>> do_shutdown = 1;
>> }
>>
>> is a repeating pattern. Perhaps it should be called
>> sev_firmware_reinit() and called by other functions.
>
>> * The rest is simplifications and streamlining.
>>
>> ---
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index e3ee68afd068..d41f5448a25b 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>> int ret, state;
>> void *blob;
>>
>> - if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
>> - sizeof(struct sev_user_data_pek_csr)))
>> + if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
>> + return -EFAULT;
>> +
>> + if (!input.address)
>> + return -EINVAL;
>> +
As per the spec, its perfectly legal to pass input.address = 0x0 and
input.length = 0x0. If userspace wants to query CSR length then it will
fill all the fields with. In response, FW will return error
(LENGTH_TO_SMALL) and input.length will be filled with the expected
length. Several command work very similar (e.g PEK_CSR,
PEK_CERT_EXPORT). A typical usage from userspace will be:
- query the length of the blob (call command with all fields set to zero)
- SEV FW will response with expected length
- userspace allocate the blob and retries the command.
>> + /* 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)
>> return -EFAULT;
>>
>> data = kzalloc(sizeof(*data), GFP_KERNEL);
>> if (!data)
>> return -ENOMEM;
>>
>> - /* allocate a temporary physical contigous buffer to store the CSR blob */
>> - blob = NULL;
>> - if (input.address) {
>> - 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;
>> + blob = kmalloc(input.length, GFP_KERNEL);
>> + if (!blob) {
>> + ret = -ENOMEM;
>> + goto e_free;
>> }
>>
>> + data->address = __psp_pa(blob);
>> + data->len = input.length;
>> +
>> ret = sev_platform_get_state(&state, &argp->error);
>> if (ret)
>> goto e_free_blob;
>> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>> do_shutdown = 1;
>> }
>>
>> - ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
>> + ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
>>
>> input.length = data->len;
>>
>> /* copy blob to userspace */
>> - if (blob &&
>> - copy_to_user((void __user *)(uintptr_t)input.address,
>> - blob, input.length)) {
>> + if (copy_to_user((void __user *)input.address, blob, input.length)) {
>> ret = -EFAULT;
>> goto e_shutdown;
>> }
>>
>> - if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
>> - sizeof(struct sev_user_data_pek_csr)))
>> + if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
>> ret = -EFAULT;
>>
>> e_shutdown:
>> if (do_shutdown)
>> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +
>> e_free_blob:
>> kfree(blob);
>> e_free:
>> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
>> ret = sev_ioctl_pdh_gen(&input);
>> break;
>>
>> - case SEV_PEK_CSR: {
>> + case SEV_PEK_CSR:
>> ret = sev_ioctl_pek_csr(&input);
>> break;
>> - }
>> +
>> default:
>> ret = -EINVAL;
>> goto out;
>>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-13 4:13 ` Brijesh Singh
@ 2017-10-13 10:20 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 10:20 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Thu, Oct 12, 2017 at 11:13:44PM -0500, Brijesh Singh wrote:
> As per the spec, its perfectly legal to pass input.address = 0x0 and
> input.length = 0x0. If userspace wants to query CSR length then it will
> fill all the fields with. In response, FW will return error
> (LENGTH_TO_SMALL) and input.length will be filled with the expected
> length. Several command work very similar (e.g PEK_CSR,
> PEK_CERT_EXPORT). A typical usage from userspace will be:
>
> - query the length of the blob (call command with all fields set to zero)
> - SEV FW will response with expected length
> - userspace allocate the blob and retries the command.
Ok, let's make that a clearer and more precise by explicitly checking
the query case:
+ /* Userspace wants to query CSR length */
+ if (!input.address && !input.length)
+ goto cmd;
and commenting why we're doing this.
The rest is cleanups.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e3ee68afd068..e10f507f9a60 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -299,36 +299,37 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
struct sev_user_data_pek_csr input;
struct sev_data_pek_csr *data;
int do_shutdown = 0;
+ void *blob = NULL;
int ret, state;
- void *blob;
- if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
- sizeof(struct sev_user_data_pek_csr)))
+ if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
return -EFAULT;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
- /* allocate a temporary physical contigous buffer to store the CSR blob */
- blob = NULL;
- if (input.address) {
- if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
- input.length > SEV_FW_BLOB_MAX_SIZE) {
- ret = -EFAULT;
- goto e_free;
- }
+ /* Userspace wants to query CSR length */
+ if (!input.address && !input.length)
+ goto cmd;
- blob = kmalloc(input.length, GFP_KERNEL);
- if (!blob) {
- ret = -ENOMEM;
- goto e_free;
- }
+ /* 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;
+ }
- data->address = __psp_pa(blob);
- data->len = input.length;
+ 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_get_state(&state, &argp->error);
if (ret)
goto e_free_blob;
@@ -349,25 +350,26 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
do_shutdown = 1;
}
- ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, &argp->error);
+ /*
+ * If we query the CSR length, FW responded with the expected length.
+ */
input.length = data->len;
- /* copy blob to userspace */
- if (blob &&
- copy_to_user((void __user *)(uintptr_t)input.address,
- blob, input.length)) {
- ret = -EFAULT;
- goto e_shutdown;
+ if (blob) {
+ if (copy_to_user((void __user *)input.address, blob, input.length)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
}
- if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
- sizeof(struct sev_user_data_pek_csr)))
+ if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
ret = -EFAULT;
e_shutdown:
if (do_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
e_free_blob:
kfree(blob);
e_free:
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command
2017-10-13 2:24 ` Brijesh Singh
2017-10-13 4:13 ` Brijesh Singh
@ 2017-10-13 9:14 ` Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 9:14 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Thu, Oct 12, 2017 at 09:24:01PM -0500, Brijesh Singh wrote:
> I assume you mean performing the SEV state check before allocating the
> memory for the CSR blob, right ?
I mean, do those first:
if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
return -EFAULT;
if (!input.address)
return -EINVAL;
/* 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)
return -EFAULT;
Because if you allocate the memory first and some of those checks fail,
you allocate in vain to free it immediately after. And you can save
yourself all that.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (5 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-13 14:53 ` Borislav Petkov
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
` (2 subsequent siblings)
9 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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 | 97 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 8038ca7aef03..861c44bf2910 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -380,6 +380,99 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
return ret;
}
+static void *copy_user_blob(u64 __user uaddr, u32 len)
+{
+ void *data;
+
+ if (!uaddr || !len)
+ return ERR_PTR(-EINVAL);
+
+ /* verify that blob length does not exceed our limit */
+ if (len > SEV_FW_BLOB_MAX_SIZE)
+ return ERR_PTR(-EINVAL);
+
+ data = kmalloc(len, GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ goto e_free;
+
+ return data;
+
+e_free:
+ kfree(data);
+ return ERR_PTR(-EFAULT);
+}
+
+static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pek_cert_import input;
+ struct sev_data_pek_cert_import *data;
+ int ret, state, do_shutdown = 0;
+ void *pek_blob, *oca_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t) argp->data,
+ sizeof(struct sev_user_data_pek_cert_import)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* copy PEK certificate blobs from userspace */
+ pek_blob = copy_user_blob(input.pek_cert_address, input.pek_cert_len);
+ if (IS_ERR(pek_blob)) {
+ ret = PTR_ERR(pek_blob);
+ goto e_free;
+ }
+
+ data->pek_cert_address = __psp_pa(pek_blob);
+ data->pek_cert_len = input.pek_cert_len;
+
+ /* copy PEK certificate blobs from userspace */
+ oca_blob = copy_user_blob(input.oca_cert_address, input.oca_cert_len);
+ if (IS_ERR(oca_blob)) {
+ ret = PTR_ERR(oca_blob);
+ goto e_free_pek;
+ }
+
+ data->oca_cert_address = __psp_pa(oca_blob);
+ data->oca_cert_len = input.oca_cert_len;
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_oca;
+
+ /*
+ * PEK_CERT_IMPORT command can be issued only when platform is in INIT
+ * state. If we are in UNINIT state then transition in INIT state
+ * before issuing the command.
+ */
+ if (state == SEV_STATE_WORKING) {
+ ret = -EBUSY;
+ goto e_free_oca;
+ } else if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_oca;
+ do_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+
+ if (do_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+
+e_free_oca:
+ kfree(oca_blob);
+e_free_pek:
+ kfree(pek_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -417,6 +510,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pek_csr(&input);
break;
}
+ case SEV_PEK_CERT_IMPORT: {
+ ret = sev_ioctl_pek_cert_import(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
@ 2017-10-13 14:53 ` Borislav Petkov
2017-10-13 16:09 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 14:53 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:06PM -0500, 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>
> ---
> drivers/crypto/ccp/psp-dev.c | 97 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 97 insertions(+)
Just minor cleanups, otherwise looks ok.
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 25a437c8d532..e61758af288f 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -392,7 +392,7 @@ static void *copy_user_blob(u64 __user uaddr, u32 len)
if (!data)
return ERR_PTR(-ENOMEM);
- if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ if (copy_from_user(data, (void __user *)uaddr, len))
goto e_free;
return data;
@@ -409,8 +409,7 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
int ret, state, do_shutdown = 0;
void *pek_blob, *oca_blob;
- if (copy_from_user(&input, (void __user *)(uintptr_t) argp->data,
- sizeof(struct sev_user_data_pek_cert_import)))
+ if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
return -EFAULT;
data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -456,10 +455,10 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
do_shutdown = 1;
}
- ret = sev_handle_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
if (do_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
e_free_oca:
kfree(oca_blob);
@@ -503,14 +502,14 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pdh_gen(&input);
break;
- case SEV_PEK_CSR: {
+ case SEV_PEK_CSR:
ret = sev_ioctl_pek_csr(&input);
break;
- }
- case SEV_PEK_CERT_IMPORT: {
+
+ case SEV_PEK_CERT_IMPORT:
ret = sev_ioctl_pek_cert_import(&input);
break;
- }
+
default:
ret = -EINVAL;
goto out;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command
2017-10-13 14:53 ` Borislav Petkov
@ 2017-10-13 16:09 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-13 16:09 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/13/2017 09:53 AM, Borislav Petkov wrote:
...
>
> - if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
> + if (copy_from_user(data, (void __user *)uaddr, len))
> goto e_free;
IIRC, typecast was needed for i386 build, but now we have depends on
X86_64 hence I will go ahead and remove the typecast from all other places.
>
> return data;
> @@ -409,8 +409,7 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
> int ret, state, do_shutdown = 0;
> void *pek_blob, *oca_blob;
>
> - if (copy_from_user(&input, (void __user *)(uintptr_t) argp->data,
> - sizeof(struct sev_user_data_pek_cert_import)))
> + if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
> return -EFAULT;
>
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> @@ -456,10 +455,10 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
> do_shutdown = 1;
> }
>
> - ret = sev_handle_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
> + ret = sev_do_cmd(SEV_CMD_PEK_CERT_IMPORT, data, &argp->error);
>
> if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>
> e_free_oca:
> kfree(oca_blob);
> @@ -503,14 +502,14 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
> ret = sev_ioctl_pdh_gen(&input);
> break;
>
> - case SEV_PEK_CSR: {
> + case SEV_PEK_CSR:
> ret = sev_ioctl_pek_csr(&input);
> break;
> - }
> - case SEV_PEK_CERT_IMPORT: {
> +
> + case SEV_PEK_CERT_IMPORT:
> ret = sev_ioctl_pek_cert_import(&input);
> break;
> - }
> +
> default:
> ret = -EINVAL;
> goto out;
>
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (6 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.8/31] crypto: ccp: Implement SEV_PEK_CERT_IMPORT " Brijesh Singh
@ 2017-10-07 1:06 ` Brijesh Singh
2017-10-13 15:01 ` Borislav Petkov
2017-10-07 18:40 ` [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Borislav Petkov
2017-10-11 16:50 ` [Part2 PATCH v5.2 12.2/31] " Brijesh Singh
9 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-07 1:06 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
The 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 | 110 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 861c44bf2910..0a069e3c7b8c 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -473,6 +473,112 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
return ret;
}
+static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
+{
+ struct sev_user_data_pdh_cert_export input;
+ struct sev_data_pdh_cert_export *data;
+ int ret, state, need_shutdown = 0;
+ void *pdh_blob, *cert_blob;
+
+ if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ pdh_blob = NULL;
+ if (input.pdh_cert_address) {
+ if (!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;
+ }
+
+ cert_blob = NULL;
+ if (input.cert_chain_address) {
+ 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;
+ }
+
+ ret = sev_platform_get_state(&state, &argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ /*
+ * CERT_EXPORT command can be issued in INIT or WORKING state.
+ * If we are in UNINIT state then transition to INIT.
+ */
+ if (state == SEV_STATE_UNINIT) {
+ ret = sev_firmware_init(&argp->error);
+ if (ret)
+ goto e_free_cert;
+
+ need_shutdown = 1;
+ }
+
+ ret = sev_handle_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+
+ input.cert_chain_len = data->cert_chain_len;
+ input.pdh_cert_len = data->pdh_cert_len;
+
+ /* copy certificate length to userspace */
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
+ sizeof(struct sev_user_data_pdh_cert_export)))
+ ret = -EFAULT;
+
+ if (ret)
+ goto e_shutdown;
+
+ /* copy PDH certificate to userspace */
+ if (pdh_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.pdh_cert_address,
+ pdh_blob, input.pdh_cert_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
+
+ /* copy certificate chain to userspace */
+ if (cert_blob &&
+ copy_to_user((void __user *)(uintptr_t)input.cert_chain_address,
+ cert_blob, input.cert_chain_len))
+ ret = -EFAULT;
+
+e_shutdown:
+ if (need_shutdown)
+ sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+e_free_cert:
+ kfree(cert_blob);
+e_free_pdh:
+ kfree(pdh_blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -514,6 +620,10 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pek_cert_import(&input);
break;
}
+ case SEV_PDH_CERT_EXPORT: {
+ ret = sev_ioctl_pdh_cert_export(&input);
+ break;
+ }
default:
ret = -EINVAL;
break;
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
@ 2017-10-13 15:01 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 15:01 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:06:07PM -0500, 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>
> ---
> 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 861c44bf2910..0a069e3c7b8c 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -473,6 +473,112 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
> return ret;
> }
>
> +static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
> +{
> + struct sev_user_data_pdh_cert_export input;
> + struct sev_data_pdh_cert_export *data;
> + int ret, state, need_shutdown = 0;
> + void *pdh_blob, *cert_blob;
> +
> + if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
> + sizeof(struct sev_user_data_pdh_cert_export)))
> + return -EFAULT;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + pdh_blob = NULL;
> + if (input.pdh_cert_address) {
Here...
> + 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;
> + }
> +
> + cert_blob = NULL;
> + if (input.cert_chain_address) {
... and here please check the full condition where userspace queries the
cert length, like before.
Otherwise, the usual cleanups:
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 5e69add4fea9..331d028f9445 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -476,8 +476,7 @@ static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
int ret, state, need_shutdown = 0;
void *pdh_blob, *cert_blob;
- if (copy_from_user(&input, (void __user *)(uintptr_t)argp->data,
- sizeof(struct sev_user_data_pdh_cert_export)))
+ if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
return -EFAULT;
data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -536,36 +535,37 @@ static int sev_ioctl_pdh_cert_export(struct sev_issue_cmd *argp)
need_shutdown = 1;
}
- ret = sev_handle_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
+ ret = sev_do_cmd(SEV_CMD_PDH_CERT_EXPORT, data, &argp->error);
input.cert_chain_len = data->cert_chain_len;
input.pdh_cert_len = data->pdh_cert_len;
/* copy certificate length to userspace */
- if (copy_to_user((void __user *)(uintptr_t)argp->data, &input,
- sizeof(struct sev_user_data_pdh_cert_export)))
+ if (copy_to_user((void __user *)argp->data, &input, sizeof(input)))
ret = -EFAULT;
if (ret)
goto e_shutdown;
/* copy PDH certificate to userspace */
- if (pdh_blob &&
- copy_to_user((void __user *)(uintptr_t)input.pdh_cert_address,
- pdh_blob, input.pdh_cert_len)) {
- ret = -EFAULT;
- goto e_shutdown;
+ if (pdh_blob) {
+ if (copy_to_user((void __user *)input.pdh_cert_address,
+ pdh_blob, input.pdh_cert_len)) {
+ ret = -EFAULT;
+ goto e_shutdown;
+ }
}
/* copy certificate chain to userspace */
- if (cert_blob &&
- copy_to_user((void __user *)(uintptr_t)input.cert_chain_address,
- cert_blob, input.cert_chain_len))
- ret = -EFAULT;
+ if (cert_blob) {
+ if (copy_to_user((void __user *)input.cert_chain_address,
+ cert_blob, input.cert_chain_len))
+ ret = -EFAULT;
+ }
e_shutdown:
if (need_shutdown)
- sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
+ sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
e_free_cert:
kfree(cert_blob);
e_free_pdh:
@@ -616,10 +616,9 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
ret = sev_ioctl_pek_cert_import(&input);
break;
- case SEV_PDH_CERT_EXPORT: {
+ case SEV_PDH_CERT_EXPORT:
ret = sev_ioctl_pdh_cert_export(&input);
break;
- }
default:
ret = -EINVAL;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (7 preceding siblings ...)
2017-10-07 1:06 ` [Part2 PATCH v5.1 12.9/31] crypto: ccp: Implement SEV_PDH_CERT_EXPORT " Brijesh Singh
@ 2017-10-07 18:40 ` Borislav Petkov
2017-10-08 13:30 ` Brijesh Singh
2017-10-11 16:50 ` [Part2 PATCH v5.2 12.2/31] " Brijesh Singh
9 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-07 18:40 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Fri, Oct 06, 2017 at 08:05:59PM -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.
>
> 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>
> ---
>
> Based on Boris feedback split this patch in 9 logical patches, they are
> numbers from 12.1 to 12.9.
>
> drivers/crypto/ccp/psp-dev.c | 244 +++++++++++++++++++++++++++++++++++++++++++
> drivers/crypto/ccp/psp-dev.h | 17 +++
> include/linux/psp-sev.h | 159 ++++++++++++++++++++++++++++
> 3 files changed, 420 insertions(+)
A bunch of fixes ontop:
* sev_fops_registered is superfluous if you can use psp->has_sev_fops
* s/sev_handle_cmd/sev_do_cmd/g - it really is sev_do_cmd(). "handle" is
something else.
* Flip misc dev reg logic in sev_ops_init()
* PSP_P2CMSG needs arg eval
* text streamlining
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index e9b776c3acb2..f0e0fc1fb512 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -31,7 +31,6 @@
#define DEVICE_NAME "sev"
static DEFINE_MUTEX(sev_cmd_mutex);
-static bool sev_fops_registered;
static struct psp_device *psp_alloc_struct(struct sp_device *sp)
{
@@ -121,7 +120,7 @@ static int sev_cmd_buffer_len(int cmd)
return 0;
}
-static int sev_handle_cmd(int cmd, void *data, int *psp_ret)
+static int sev_do_cmd(int cmd, void *data, int *psp_ret)
{
unsigned int phys_lsb, phys_msb;
struct psp_device *psp;
@@ -182,26 +181,26 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
return -ENOTTY;
}
-const struct file_operations sev_fops = {
+static const struct file_operations sev_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = sev_ioctl,
};
int sev_platform_init(struct sev_data_init *data, int *error)
{
- return sev_handle_cmd(SEV_CMD_INIT, data, error);
+ return sev_do_cmd(SEV_CMD_INIT, data, error);
}
EXPORT_SYMBOL_GPL(sev_platform_init);
int sev_platform_shutdown(int *error)
{
- return sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, error);
+ return sev_do_cmd(SEV_CMD_SHUTDOWN, 0, error);
}
EXPORT_SYMBOL_GPL(sev_platform_shutdown);
int sev_platform_status(struct sev_data_status *data, int *error)
{
- return sev_handle_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
+ return sev_do_cmd(SEV_CMD_PLATFORM_STATUS, data, error);
}
EXPORT_SYMBOL_GPL(sev_platform_status);
@@ -211,58 +210,58 @@ int sev_issue_cmd_external_user(struct file *filep, unsigned int cmd,
if (!filep || filep->f_op != &sev_fops)
return -EBADF;
- return sev_handle_cmd(cmd, data, error);
+ 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_handle_cmd(SEV_CMD_DEACTIVATE, data, 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_handle_cmd(SEV_CMD_ACTIVATE, data, 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_handle_cmd(SEV_CMD_DECOMMISSION, data, 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_handle_cmd(SEV_CMD_DF_FLUSH, 0, 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 miscdevice *misc = &psp->sev_misc;
- int ret = 0;
+ int ret;
/*
- * SEV feature support can be detected on the multiple devices but the
- * SEV FW commands must be issued on the master. During probe time we
- * do not know the master hence we create /dev/sev on the first device
- * probe. sev_handle_cmd() finds the right master device to when issuing
- * the command to the firmware.
+ * 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_fops_registered) {
- misc->minor = MISC_DYNAMIC_MINOR;
- misc->name = DEVICE_NAME;
- misc->fops = &sev_fops;
-
- ret = misc_register(misc);
- if (!ret) {
- sev_fops_registered = true;
- psp->has_sev_fops = true;
- init_waitqueue_head(&psp->sev_int_queue);
- dev_info(psp->dev, "registered SEV device\n");
- }
+ if (psp->has_sev_fops)
+ return 0;
+
+ misc->minor = MISC_DYNAMIC_MINOR;
+ misc->name = DEVICE_NAME;
+ misc->fops = &sev_fops;
+
+ ret = misc_register(misc);
+ if (!ret) {
+ psp->has_sev_fops = true;
+ init_waitqueue_head(&psp->sev_int_queue);
+ dev_info(psp->dev, "registered SEV device\n");
}
return ret;
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 6e8f83b41521..60a33f5ff79f 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -36,7 +36,7 @@
#define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
#define PSP_FEATURE_REG PSP_C2PMSG(63)
-#define PSP_P2CMSG(_num) (_num << 2)
+#define PSP_P2CMSG(_num) ((_num) << 2)
#define PSP_CMD_COMPLETE_REG 1
#define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 2b334fd853c9..10b843cce75f 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -512,8 +512,7 @@ struct sev_data_dbg {
u32 len; /* In */
} __packed;
-#if defined(CONFIG_CRYPTO_DEV_SP_PSP)
-
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
/**
* sev_platform_init - perform SEV INIT command
*
@@ -562,9 +561,9 @@ int sev_platform_status(struct sev_data_status *status, int *error);
* sev_issue_cmd_external_user - issue SEV command by other driver with a file
* handle.
*
- * The function can be used by other drivers to issue a SEV command on
- * behalf by userspace. The caller must pass a valid SEV file descriptor
- * so that we know that caller has access to SEV device.
+ * 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
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-07 18:40 ` [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Borislav Petkov
@ 2017-10-08 13:30 ` Brijesh Singh
2017-10-08 14:00 ` Borislav Petkov
2017-10-11 14:19 ` Borislav Petkov
0 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-08 13:30 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/7/17 1:40 PM, Borislav Petkov wrote:
...
> A bunch of fixes ontop:
>
> * sev_fops_registered is superfluous if you can use psp->has_sev_fops
I am okay with all your fixes except this one. I will add my comment below.
...
> static int sev_ops_init(struct psp_device *psp)
> {
> struct miscdevice *misc = &psp->sev_misc;
> - int ret = 0;
> + int ret;
>
> /*
> - * SEV feature support can be detected on the multiple devices but the
> - * SEV FW commands must be issued on the master. During probe time we
> - * do not know the master hence we create /dev/sev on the first device
> - * probe. sev_handle_cmd() finds the right master device to when issuing
> - * the command to the firmware.
> + * 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_fops_registered) {
> - misc->minor = MISC_DYNAMIC_MINOR;
> - misc->name = DEVICE_NAME;
> - misc->fops = &sev_fops;
> -
> - ret = misc_register(misc);
> - if (!ret) {
> - sev_fops_registered = true;
> - psp->has_sev_fops = true;
> - init_waitqueue_head(&psp->sev_int_queue);
> - dev_info(psp->dev, "registered SEV device\n");
> - }
> + if (psp->has_sev_fops)
> + return 0;
> +
This will always be false. The struct psp_device is used for storing
per-device instance.
> + misc->minor = MISC_DYNAMIC_MINOR;
> + misc->name = DEVICE_NAME;
> + misc->fops = &sev_fops;
> +
> + ret = misc_register(misc);
> + if (!ret) {
> + psp->has_sev_fops = true;
> + init_waitqueue_head(&psp->sev_int_queue);
> + dev_info(psp->dev, "registered SEV device\n");
> }
During the device probe, sev_ops_init() will be called for every device
instance which claims to support the SEV. One of the device will be
'master' but we don't the master until we probe all the instances. Hence
the probe for all SEV devices must return success.
With your changes, the first device instance will able to create
/dev/sev node but all other instances will fail hence the probe routine
for other instances will also fail.
Basically we need some variable which is outside the per-device
structure so that we don't end up creating multiple /dev/sev nodes. If
needed, I think we can remove 'has_sev_fops' variable from struct
psp_device if we decide to dynamic alloc 'struct miscdevice sev_misc' in
struct psp_device. The 'has_sev_fops' is mainly used in sev_exit(). If
we decide to dynamic alloc sev_misc then in sev_exit() we can use
psp->sev_misc != NULL instead of psp->has_sev_ops.
>
> return ret;
> diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
> index 6e8f83b41521..60a33f5ff79f 100644
> --- a/drivers/crypto/ccp/psp-dev.h
> +++ b/drivers/crypto/ccp/psp-dev.h
> @@ -36,7 +36,7 @@
> #define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
> #define PSP_FEATURE_REG PSP_C2PMSG(63)
>
> -#define PSP_P2CMSG(_num) (_num << 2)
> +#define PSP_P2CMSG(_num) ((_num) << 2)
> #define PSP_CMD_COMPLETE_REG 1
> #define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
>
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 2b334fd853c9..10b843cce75f 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -512,8 +512,7 @@ struct sev_data_dbg {
> u32 len; /* In */
> } __packed;
>
> -#if defined(CONFIG_CRYPTO_DEV_SP_PSP)
> -
> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
> /**
> * sev_platform_init - perform SEV INIT command
> *
> @@ -562,9 +561,9 @@ int sev_platform_status(struct sev_data_status *status, int *error);
> * sev_issue_cmd_external_user - issue SEV command by other driver with a file
> * handle.
> *
> - * The function can be used by other drivers to issue a SEV command on
> - * behalf by userspace. The caller must pass a valid SEV file descriptor
> - * so that we know that caller has access to SEV device.
> + * 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
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-08 13:30 ` Brijesh Singh
@ 2017-10-08 14:00 ` Borislav Petkov
2017-10-09 0:11 ` Brijesh Singh
2017-10-11 14:19 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-08 14:00 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 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
> During the device probe, sev_ops_init() will be called for every device
> instance which claims to support the SEV. One of the device will be
> 'master' but we don't the master until we probe all the instances. Hence
> the probe for all SEV devices must return success.
I still am wondering whether that design with multiple devices - master
and non-master devices is optimal. Why isn't the security processor a
single driver which provides the whole functionality, PSP including? Why
do you need all that register and unregister glue and get_master bla if
you can simply put the whole thing in a single module?
And the fact that you need a global variable to mark that you've
registered the misc device should already tell you that something's
not optimal. Because if you had a single driver, it will go, detect
the whole functionality, initialize it, register services and be done
with it. No registering of devices, no finding of masters, no global
variables, no unnecessary glue.
IOW, in this diagram:
+--- CCP
|
AMD-SP --|
| +--- SEV
| |
+---- PSP ---*
|
+---- TEE
why isn't the whole PSP functionality part of drivers/crypto/ccp/sp-dev.c ?
That driver is almost barebones minimal thing. You can very well add the
PSP/SEV stuff in there and if there's an *actual* reason to carve pieces
out, only then to do so, not to split it now unnecessarily and make your
life complicated for no reason.
Or am I missing some obvious and important reason?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-08 14:00 ` Borislav Petkov
@ 2017-10-09 0:11 ` Brijesh Singh
2017-10-09 15:21 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-09 0:11 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/8/17 9:00 AM, Borislav Petkov wrote:
> On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
>> During the device probe, sev_ops_init() will be called for every device
>> instance which claims to support the SEV. One of the device will be
>> 'master' but we don't the master until we probe all the instances. Hence
>> the probe for all SEV devices must return success.
> I still am wondering whether that design with multiple devices - master
> and non-master devices is optimal. Why isn't the security processor a
> single driver which provides the whole functionality, PSP including? Why
> do you need all that register and unregister glue and get_master bla if
> you can simply put the whole thing in a single module?
There is a single security processor driver (ccp) which provides the
complete functionality including PSP. But the driver should be able to
work with multiple devices. e.g In my 2P EPYC configuration, security
processor driver is used for the following devices
02:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
14:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
22:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
23:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
31:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
32:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
41:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
42:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
51:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
52:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
61:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
62:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
71:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1456
72:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
1468
Some of the these devices support CCP only and some support both PSP and
CCP. It's possible that multiple devices support the PSP functionality
but only one of them is master which can be used for issuing SEV
commands. There isn't a register which we can read to determine whether
the device is master. We have to probe all the devices which supports
the PSP to determine which one of them is a master.
> And the fact that you need a global variable to mark that you've
> registered the misc device should already tell you that something's
> not optimal. Because if you had a single driver, it will go, detect
> the whole functionality, initialize it, register services and be done
> with it. No registering of devices, no finding of masters, no global
> variables, no unnecessary glue.
>
> IOW, in this diagram:
>
> +--- CCP
> |
> AMD-SP --|
> | +--- SEV
> | |
> +---- PSP ---*
> |
> +---- TEE
>
> why isn't the whole PSP functionality part of drivers/crypto/ccp/sp-dev.c ?
>
> That driver is almost barebones minimal thing. You can very well add the
> PSP/SEV stuff in there and if there's an *actual* reason to carve pieces
> out, only then to do so, not to split it now unnecessarily and make your
> life complicated for no reason.
I was trying to follow the CCP model -- in which sp-dev.c simply
forwards the call to ccp-dev.c which does the real work. Currently,
sev-dev.c contains barebone common code. IMO, keeping all the PSP
private functions and data structure outside the sp-dev.c/.h is right
thing. Having said that, I am okay with moving all the PSP stuff in
sp-dev.c but before we do that lets see what CCP maintainers say.
Tom and Gary, comments please ?
Additionally, I would like to highlight that if we decide to go with
moving all the PSP functionality in sp-dev.c then we have to add #ifdef
CONFIG_CRYPTO_DEV_SP_PSP because PSP feature depends on X86_66, whereas
the sp-dev.c gets compiled for all architectures (including aarch64,
i386 and x86_64).
>
> Or am I missing some obvious and important reason?
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-09 0:11 ` Brijesh Singh
@ 2017-10-09 15:21 ` Borislav Petkov
2017-10-10 15:00 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-09 15: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 08, 2017 at 07:11:04PM -0500, Brijesh Singh wrote:
> There is a single security processor driver (ccp) which provides the
> complete functionality including PSP. But the driver should be able to
> work with multiple devices. e.g In my 2P EPYC configuration, security
> processor driver is used for the following devices
>
> 02:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1456
So we have a lot of drivers which claim more than one PCI device. It is
not mandatory to have a driver per PCI device. Actually, the decisive
argument is what is the easiest way to manage those devices and what
makes the communication between them the easiest.
> 03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1468
> 13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1456
Btw, what do those PCI functions each do? Public PPR doesn't have them
documented.
> Some of the these devices support CCP only and some support both PSP and
> CCP. It's possible that multiple devices support the PSP functionality
> but only one of them is master which can be used for issuing SEV
> commands. There isn't a register which we can read to determine whether
> the device is master. We have to probe all the devices which supports
> the PSP to determine which one of them is a master.
Sure, and if you manage all the devices in a single driver, you can
simply keep them all in a linked list or in an array and iterating over
them is trivial.
Because right now you have
1. sp-pci.c::sp_pci_probe() execute upon the PCI device detection
2. at some point, it does sp-dev.c::sp_init() which decides whether CCP or PSP
3. If PSP, it calls pcp-dev.c::psp_dev_init() which gets that
sp->dev_vdata->psp_vdata which is nothing more than a simple offset
0x10500 which is where the PSP io regs are. For example, if this offset
is hardcoded, why are we even passing that vdata? Just set psp->io_regs =
0x10500. No need for all that passing of structs around.
4. and finally, after that *whole* init has been done, you get to do
->set_psp_master_device(sp);
Or, you can save yourself all that jumping through hoops, merge sp-pci.c
and sp-dev.c into a single sp.c and put *everything* sp-related into
it. And then do the whole work of picking hw apart, detection and
configuration in sp_pci_probe() and have helper functions preparing and
configuring the device.
At the end, it adds it to the list of devices sp.c manages and done. You
actually have that list already:
static LIST_HEAD(sp_units);
in sp-dev.c.
You don't need the set_master thing either - you simply set the
sp_dev_master pointer inside sp.c
sp_init() can then go and you can replace it with its function body,
deciding whether it is a CCP or PSP and then call the respective
function which is also in sp.c or ccp-dev.c
And then all those separate compilation units and the interfaces between
them disappear - you have only the calls into the PSP and that's it.
Btw, the CCP thing could remain separate initially, I guess, with all
that ccp-* stuff in there.
> I was trying to follow the CCP model -- in which sp-dev.c simply
> forwards the call to ccp-dev.c which does the real work.
And you don't really need that - you can do the real work directly in
sp-dev.c or sp.c or whatever.
> Currently, sev-dev.c contains barebone common code. IMO, keeping all
> the PSP private functions and data structure outside the sp-dev.c/.h
> is right thing.
By this model probably, but it causes all that init and registration
jump-through-hoops for no real reason. It is basically wasting cycles
and energy.
I'm all for splitting if it makes sense. But right now I don't see much
sense in this - it is basically a bunch of small compilation units
calling each other. And they could be merged into a single sp.c which
does it all in one go, without a lot of blabla.
> Additionally, I would like to highlight that if we decide to go with
> moving all the PSP functionality in sp-dev.c then we have to add #ifdef
> CONFIG_CRYPTO_DEV_SP_PSP because PSP feature depends on X86_66, whereas
> the sp-dev.c gets compiled for all architectures (including aarch64,
> i386 and x86_64).
That's fine. You can build it on 32-bit but add to the init function
if (IS_ENABLED(CONFIG_X86_32))
return -ENODEV;
and be done with it. No need for the ifdeffery.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-09 15:21 ` Borislav Petkov
@ 2017-10-10 15:00 ` Brijesh Singh
2017-10-10 18:43 ` Tom Lendacky
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-10 15:00 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/09/2017 10:21 AM, Borislav Petkov wrote:
...
>
>> 03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
>> 1468
>> 13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
>> 1456
>
> Btw, what do those PCI functions each do? Public PPR doesn't have them
> documented.
Looking at the pci_device_id table (sp-pci.c), the devices id 0x1468
provides the support CCP support directly on the x86-side and device id
0x1456 provides the support for both CCP and PSP features through the
AMD Secure Processor (AMD-SP).
>
> Sure, and if you manage all the devices in a single driver, you can
> simply keep them all in a linked list or in an array and iterating over
> them is trivial.
>
> Because right now you have
>
> 1. sp-pci.c::sp_pci_probe() execute upon the PCI device detection
>
> 2. at some point, it does sp-dev.c::sp_init() which decides whether CCP or PSP
>
> 3. If PSP, it calls pcp-dev.c::psp_dev_init() which gets that
> sp->dev_vdata->psp_vdata which is nothing more than a simple offset
> 0x10500 which is where the PSP io regs are. For example, if this offset
> is hardcoded, why are we even passing that vdata? Just set psp->io_regs =
> 0x10500. No need for all that passing of structs around.
>
> 4. and finally, after that *whole* init has been done, you get to do
> ->set_psp_master_device(sp);
>
> Or, you can save yourself all that jumping through hoops, merge sp-pci.c
> and sp-dev.c into a single sp.c and put *everything* sp-related into
> it. And then do the whole work of picking hw apart, detection and
> configuration in sp_pci_probe() and have helper functions preparing and
> configuring the device.
>
> At the end, it adds it to the list of devices sp.c manages and done. You
> actually have that list already:
>
> static LIST_HEAD(sp_units);
>
> in sp-dev.c.
>
> You don't need the set_master thing either - you simply set the
> sp_dev_master pointer inside sp.c
>
I was trying to avoid putting PSP/SEV specific changes in sp-dev.*
files. But if sp.c approach is acceptable to the maintainer then I can
work towards merging sp-dev.c and sp-pci.c into sp.c and then add the
PSP/SEV support.
> sp_init() can then go and you can replace it with its function body,
> deciding whether it is a CCP or PSP and then call the respective
> function which is also in sp.c or ccp-dev.c
>
> And then all those separate compilation units and the interfaces between
> them disappear - you have only the calls into the PSP and that's it.
>
> Btw, the CCP thing could remain separate initially, I guess, with all
> that ccp-* stuff in there.
>
Yep, if we decide to go with your recommended approach then we should
leave the CCP as-is for now.
>> I was trying to follow the CCP model -- in which sp-dev.c simply
>> forwards the call to ccp-dev.c which does the real work.
>
> And you don't really need that - you can do the real work directly in
> sp-dev.c or sp.c or whatever.
> >> Currently, sev-dev.c contains barebone common code. IMO, keeping all
>> the PSP private functions and data structure outside the sp-dev.c/.h
>> is right thing.
>
> By this model probably, but it causes all that init and registration
> jump-through-hoops for no real reason. It is basically wasting cycles
> and energy.
>
> I'm all for splitting if it makes sense. But right now I don't see much
> sense in this - it is basically a bunch of small compilation units
> calling each other. And they could be merged into a single sp.c which
> does it all in one go, without a lot of blabla.
>> Additionally, I would like to highlight that if we decide to go with
>> moving all the PSP functionality in sp-dev.c then we have to add #ifdef
>> CONFIG_CRYPTO_DEV_SP_PSP because PSP feature depends on X86_66, whereas
>> the sp-dev.c gets compiled for all architectures (including aarch64,
>> i386 and x86_64).
>
> That's fine. You can build it on 32-bit but add to the init function
>
> if (IS_ENABLED(CONFIG_X86_32))
> return -ENODEV;
>
> and be done with it. No need for the ifdeffery.
>
OK, i will use IS_ENABLED where applicable.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-10 15:00 ` Brijesh Singh
@ 2017-10-10 18:43 ` Tom Lendacky
2017-10-10 20:04 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Tom Lendacky @ 2017-10-10 18:43 UTC (permalink / raw)
To: Brijesh Singh, Borislav Petkov
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, linux-crypto, kvm, linux-kernel
On 10/10/2017 10:00 AM, Brijesh Singh wrote:
>
>
> On 10/09/2017 10:21 AM, Borislav Petkov wrote:
> ...
>
>>
>>> 03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
>>> 1468
>>> 13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
>>> 1456
>>
>> Btw, what do those PCI functions each do? Public PPR doesn't have them
>> documented.
>
>
> Looking at the pci_device_id table (sp-pci.c), the devices id 0x1468
> provides the support CCP support directly on the x86-side and device id
> 0x1456 provides the support for both CCP and PSP features through the AMD
> Secure Processor (AMD-SP).
>
>
>>
>> Sure, and if you manage all the devices in a single driver, you can
>> simply keep them all in a linked list or in an array and iterating over
>> them is trivial.
>>
>> Because right now you have
>>
>> 1. sp-pci.c::sp_pci_probe() execute upon the PCI device detection
>>
>> 2. at some point, it does sp-dev.c::sp_init() which decides whether CCP
>> or PSP
>>
>> 3. If PSP, it calls pcp-dev.c::psp_dev_init() which gets that
>> sp->dev_vdata->psp_vdata which is nothing more than a simple offset
>> 0x10500 which is where the PSP io regs are. For example, if this offset
>> is hardcoded, why are we even passing that vdata? Just set psp->io_regs =
>> 0x10500. No need for all that passing of structs around.
Maybe for the very first implementation we could do that and that was what
was originally done for the CCP. But as you can see the CCP does not have
a set register offset between various iterations of the device and it can
be expected the same will hold true for the PSP. This just makes future
changes easier in order to support newer devices.
>>
>> 4. and finally, after that *whole* init has been done, you get to do
>> ->set_psp_master_device(sp);
>>
>> Or, you can save yourself all that jumping through hoops, merge sp-pci.c
>> and sp-dev.c into a single sp.c and put *everything* sp-related into
>> it. And then do the whole work of picking hw apart, detection and
>> configuration in sp_pci_probe() and have helper functions preparing and
>> configuring the device.
>>
>> At the end, it adds it to the list of devices sp.c manages and done. You
>> actually have that list already:
>>
>> static LIST_HEAD(sp_units);
>>
>> in sp-dev.c.
>>
>> You don't need the set_master thing either - you simply set the
>> sp_dev_master pointer inside sp.c
>>
>
>
> I was trying to avoid putting PSP/SEV specific changes in sp-dev.* files.
> But if sp.c approach is acceptable to the maintainer then I can work
> towards merging sp-dev.c and sp-pci.c into sp.c and then add the PSP/SEV
> support.
I would prefer to keep things separated as they are. The common code is
one place and the pci/platform specific code resides in unique files. For
sp-pci.c, it can be excluded from compilation if CONFIG_PCI is not defined
vs. adding #ifdefs into sp-dev.c or sp.c. The code is working nicely and,
at least to me, seems easily maintainable this way. If we really want to
avoid the extra calls during probing, etc. then we can take a closer look
afterwards and determine what is the best approach taking into account
the CCP and some of the other PSP functionality that is coming.
Thanks,
Tom
>
>
>> sp_init() can then go and you can replace it with its function body,
>> deciding whether it is a CCP or PSP and then call the respective
>> function which is also in sp.c or ccp-dev.c
>>
>> And then all those separate compilation units and the interfaces between
>> them disappear - you have only the calls into the PSP and that's it.
>>
>> Btw, the CCP thing could remain separate initially, I guess, with all
>> that ccp-* stuff in there.
>>
>
> Yep, if we decide to go with your recommended approach then we should
> leave the CCP as-is for now.
>
>
>>> I was trying to follow the CCP model -- in which sp-dev.c simply
>>> forwards the call to ccp-dev.c which does the real work.
>>
>> And you don't really need that - you can do the real work directly in
>> sp-dev.c or sp.c or whatever.
>> >> Currently, sev-dev.c contains barebone common code. IMO, keeping all
>>> the PSP private functions and data structure outside the sp-dev.c/.h
>>> is right thing.
>>
>> By this model probably, but it causes all that init and registration
>> jump-through-hoops for no real reason. It is basically wasting cycles
>> and energy.
>>
>> I'm all for splitting if it makes sense. But right now I don't see much
>> sense in this - it is basically a bunch of small compilation units
>> calling each other. And they could be merged into a single sp.c which
>> does it all in one go, without a lot of blabla.
>
>>> Additionally, I would like to highlight that if we decide to go with
>>> moving all the PSP functionality in sp-dev.c then we have to add #ifdef
>>> CONFIG_CRYPTO_DEV_SP_PSP because PSP feature depends on X86_66, whereas
>>> the sp-dev.c gets compiled for all architectures (including aarch64,
>>> i386 and x86_64).
>>
>> That's fine. You can build it on 32-bit but add to the init function
>>
>> if (IS_ENABLED(CONFIG_X86_32))
>> return -ENODEV;
>>
>> and be done with it. No need for the ifdeffery.
>>
>
> OK, i will use IS_ENABLED where applicable.
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-10 18:43 ` Tom Lendacky
@ 2017-10-10 20:04 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-10 20:04 UTC (permalink / raw)
To: Tom Lendacky
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, linux-crypto, kvm, linux-kernel
On Tue, Oct 10, 2017 at 01:43:22PM -0500, Tom Lendacky wrote:
> Maybe for the very first implementation we could do that and that was what
> was originally done for the CCP. But as you can see the CCP does not have
> a set register offset between various iterations of the device and it can
> be expected the same will hold true for the PSP. This just makes future
> changes easier in order to support newer devices.
Well, that's a simple switch-case statement which maps device iteration
to offset.
> I would prefer to keep things separated as they are. The common code is
> one place and the pci/platform specific code resides in unique files. For
> sp-pci.c, it can be excluded from compilation if CONFIG_PCI is not defined
> vs. adding #ifdefs into sp-dev.c or sp.c. The code is working nicely and,
> at least to me, seems easily maintainable this way.
But you do see that you're doing a bunch of unnecessary things during
probing. And all those different devices: SP, CCP, PSP, TEE and whatnot,
they're just too granulary and it is a bunch of registration code and
one compilation unit calling into the other for no good reason. Or at
least I don't see it.
> If we really want to avoid the extra calls during probing, etc.
> then we can take a closer look afterwards and determine what is the
> best approach taking into account the CCP and some of the other PSP
> functionality that is coming.
And that coming functionality won't make things easier - you'll most
likely have more things wanting to talk to more other things. But ok,
your call. Just note that changing things later is always harder.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-08 13:30 ` Brijesh Singh
2017-10-08 14:00 ` Borislav Petkov
@ 2017-10-11 14:19 ` Borislav Petkov
2017-10-11 14:23 ` Brijesh Singh
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-11 14:19 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 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
> Basically we need some variable which is outside the per-device
> structure so that we don't end up creating multiple /dev/sev nodes. If
> needed, I think we can remove 'has_sev_fops' variable from struct
> psp_device if we decide to dynamic alloc 'struct miscdevice sev_misc' in
> struct psp_device. The 'has_sev_fops' is mainly used in sev_exit(). If
> we decide to dynamic alloc sev_misc then in sev_exit() we can use
> psp->sev_misc != NULL instead of psp->has_sev_ops.
Yap, that sounds better than an explicit variable.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-11 14:19 ` Borislav Petkov
@ 2017-10-11 14:23 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 14:23 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/11/2017 09:19 AM, Borislav Petkov wrote:
> On Sun, Oct 08, 2017 at 08:30:47AM -0500, Brijesh Singh wrote:
>> Basically we need some variable which is outside the per-device
>> structure so that we don't end up creating multiple /dev/sev nodes. If
>> needed, I think we can remove 'has_sev_fops' variable from struct
>> psp_device if we decide to dynamic alloc 'struct miscdevice sev_misc' in
>> struct psp_device. The 'has_sev_fops' is mainly used in sev_exit(). If
>> we decide to dynamic alloc sev_misc then in sev_exit() we can use
>> psp->sev_misc != NULL instead of psp->has_sev_ops.
>
> Yap, that sounds better than an explicit variable.
>
Sure, I will implement it and send you v5.2. thanks
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-07 1:05 ` [Part2 PATCH v5.1 12.1/31] " Brijesh Singh
` (8 preceding siblings ...)
2017-10-07 18:40 ` [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Borislav Petkov
@ 2017-10-11 16:50 ` Brijesh Singh
2017-10-12 14:08 ` Borislav Petkov
2017-10-12 18:21 ` Borislav Petkov
9 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-11 16:50 UTC (permalink / raw)
To: bp
Cc: Brijesh Singh, Paolo Bonzini, Radim Krčmář,
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>
---
Make it as a second patch in the series (changes from 12.1 -> 12.2)
Changes since v5.1:
* text streamlining (from Boris)
* rename sev_handle_cmd -> sev_do_cmd (from Boris)
* PSP_P2CMSG needs arg eval (from Boris)
* use #ifdef instead of #if defined() (from Boris)
drivers/crypto/ccp/psp-dev.c | 251 +++++++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/psp-dev.h | 16 +++
include/linux/psp-sev.h | 159 +++++++++++++++++++++++++++
3 files changed, 426 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index b5789f878560..175cb3c3b8ef 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -23,9 +23,16 @@
#include <linux/hw_random.h>
#include <linux/ccp.h>
+#include <uapi/linux/psp-sev.h>
+
#include "sp-dev.h"
#include "psp-dev.h"
+#define DEVICE_NAME "sev"
+
+static DEFINE_MUTEX(sev_cmd_mutex);
+static bool sev_fops_registered;
+
static struct psp_device *psp_alloc_struct(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -45,9 +52,246 @@ 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 int sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
+{
+ psp->sev_int_rcvd = 0;
+
+ wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
+ *reg = ioread32(psp->io_regs + PSP_CMDRESP);
+
+ return 0;
+}
+
+static int sev_cmd_buffer_len(int cmd)
+{
+ switch (cmd) {
+ case SEV_CMD_INIT: return sizeof(struct sev_data_init);
+ case SEV_CMD_PLATFORM_STATUS: return sizeof(struct sev_data_status);
+ case SEV_CMD_PEK_CSR: return sizeof(struct sev_data_pek_csr);
+ case SEV_CMD_PEK_CERT_IMPORT: return sizeof(struct sev_data_pek_cert_import);
+ case SEV_CMD_PDH_CERT_EXPORT: return sizeof(struct sev_data_pdh_cert_export);
+ case SEV_CMD_LAUNCH_START: return sizeof(struct sev_data_launch_start);
+ case SEV_CMD_LAUNCH_UPDATE_DATA: return sizeof(struct sev_data_launch_update_data);
+ case SEV_CMD_LAUNCH_UPDATE_VMSA: return sizeof(struct sev_data_launch_update_vmsa);
+ case SEV_CMD_LAUNCH_FINISH: return sizeof(struct sev_data_launch_finish);
+ case SEV_CMD_LAUNCH_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;
+ struct psp_device *psp;
+ unsigned int reg, ret;
+ 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);
+
+ ret = sev_wait_cmd_ioc(psp, ®);
+ if (ret)
+ goto unlock;
+
+ if (psp_ret)
+ *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
+
+ if (reg & PSP_CMDRESP_ERR_MASK) {
+ dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
+ cmd, reg & PSP_CMDRESP_ERR_MASK);
+ ret = -EIO;
+ }
+
+unlock:
+ mutex_unlock(&sev_cmd_mutex);
+ print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
+ sev_cmd_buffer_len(cmd), false);
+ return ret;
+}
+
+static 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,
+};
+
+int sev_platform_init(struct sev_data_init *data, int *error)
+{
+ return sev_do_cmd(SEV_CMD_INIT, data, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_init);
+
+int sev_platform_shutdown(int *error)
+{
+ return sev_do_cmd(SEV_CMD_SHUTDOWN, 0, error);
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
+int sev_platform_status(struct sev_data_status *data, int *error)
+{
+ return sev_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;
+ struct miscdevice *misc;
+ 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_fops_registered) {
+
+ misc = devm_kzalloc(dev, sizeof(*misc), GFP_KERNEL);
+ if (!misc)
+ return -ENOMEM;
+
+ misc->minor = MISC_DYNAMIC_MINOR;
+ misc->name = DEVICE_NAME;
+ misc->fops = &sev_fops;
+
+ ret = misc_register(misc);
+ if (ret)
+ return ret;
+
+ sev_fops_registered = true;
+ psp->sev_misc = misc;
+ init_waitqueue_head(&psp->sev_int_queue);
+ 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 psp_device *psp)
+{
+ if (psp->sev_misc)
+ misc_deregister(psp->sev_misc);
+}
+
int psp_dev_init(struct sp_device *sp)
{
struct device *dev = sp->dev;
@@ -84,11 +328,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 +351,6 @@ void psp_dev_destroy(struct sp_device *sp)
{
struct psp_device *psp = sp->psp_data;
+ sev_exit(psp);
sp_free_psp_irq(sp, psp);
}
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 55b7808367c3..7a781ec20684 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -25,9 +25,21 @@
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
#include <linux/dmaengine.h>
+#include <linux/psp-sev.h>
+#include <linux/miscdevice.h>
#include "sp-dev.h"
+#define PSP_C2PMSG(_num) ((_num) << 2)
+#define PSP_CMDRESP PSP_C2PMSG(32)
+#define PSP_CMDBUFF_ADDR_LO PSP_C2PMSG(56)
+#define PSP_CMDBUFF_ADDR_HI PSP_C2PMSG(57)
+#define PSP_FEATURE_REG PSP_C2PMSG(63)
+
+#define PSP_P2CMSG(_num) ((_num) << 2)
+#define PSP_CMD_COMPLETE_REG 1
+#define PSP_CMD_COMPLETE PSP_P2CMSG(PSP_CMD_COMPLETE_REG)
+
#define PSP_P2CMSG_INTEN 0x0110
#define PSP_P2CMSG_INTSTS 0x0114
@@ -54,6 +66,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 miscdevice *sev_misc;
};
#endif /* __PSP_DEV_H */
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 496375d7f6a9..5d562d49deac 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -512,4 +512,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_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_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] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-11 16:50 ` [Part2 PATCH v5.2 12.2/31] " Brijesh Singh
@ 2017-10-12 14:08 ` Borislav Petkov
2017-10-12 21:11 ` Brijesh Singh
2017-10-12 18:21 ` Borislav Petkov
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 14:08 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Wed, Oct 11, 2017 at 11:50:30AM -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.
>
> 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>
> ---
> Make it as a second patch in the series (changes from 12.1 -> 12.2)
>
> Changes since v5.1:
> * text streamlining (from Boris)
> * rename sev_handle_cmd -> sev_do_cmd (from Boris)
> * PSP_P2CMSG needs arg eval (from Boris)
> * use #ifdef instead of #if defined() (from Boris)
>
> drivers/crypto/ccp/psp-dev.c | 251 +++++++++++++++++++++++++++++++++++++++++++
> drivers/crypto/ccp/psp-dev.h | 16 +++
> include/linux/psp-sev.h | 159 +++++++++++++++++++++++++++
> 3 files changed, 426 insertions(+)
>
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index b5789f878560..175cb3c3b8ef 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -23,9 +23,16 @@
> #include <linux/hw_random.h>
> #include <linux/ccp.h>
>
> +#include <uapi/linux/psp-sev.h>
> +
> #include "sp-dev.h"
> #include "psp-dev.h"
>
> +#define DEVICE_NAME "sev"
> +
> +static DEFINE_MUTEX(sev_cmd_mutex);
> +static bool sev_fops_registered;
Well, if you're going to have a global var, why not pull up the misc
device instead?
And mind you, I've moved out this assignments:
+ psp->sev_misc = psp_misc_dev;
+ init_waitqueue_head(&psp->sev_int_queue);
+ dev_info(dev, "registered SEV device\n");
outside of the if-conditional as I'm assuming you want to do this for
each psp device for which sev_ops_init() is called.
Or am I wrong here?
---
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 175cb3c3b8ef..d50aaa1ca75b 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -31,7 +31,7 @@
#define DEVICE_NAME "sev"
static DEFINE_MUTEX(sev_cmd_mutex);
-static bool sev_fops_registered;
+static struct miscdevice *psp_misc_dev;
static struct psp_device *psp_alloc_struct(struct sp_device *sp)
{
@@ -242,7 +242,6 @@ EXPORT_SYMBOL_GPL(sev_guest_df_flush);
static int sev_ops_init(struct psp_device *psp)
{
struct device *dev = psp->dev;
- struct miscdevice *misc;
int ret;
/*
@@ -252,26 +251,24 @@ 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_fops_registered) {
-
- misc = devm_kzalloc(dev, sizeof(*misc), GFP_KERNEL);
- if (!misc)
+ if (!psp_misc_dev) {
+ psp_misc_dev = devm_kzalloc(dev, sizeof(struct miscdevice), GFP_KERNEL);
+ if (!psp_misc_dev)
return -ENOMEM;
- misc->minor = MISC_DYNAMIC_MINOR;
- misc->name = DEVICE_NAME;
- misc->fops = &sev_fops;
+ psp_misc_dev->minor = MISC_DYNAMIC_MINOR;
+ psp_misc_dev->name = DEVICE_NAME;
+ psp_misc_dev->fops = &sev_fops;
- ret = misc_register(misc);
+ ret = misc_register(psp_misc_dev);
if (ret)
return ret;
-
- sev_fops_registered = true;
- psp->sev_misc = misc;
- init_waitqueue_head(&psp->sev_int_queue);
- dev_info(dev, "registered SEV device\n");
}
+ psp->sev_misc = psp_misc_dev;
+ init_waitqueue_head(&psp->sev_int_queue);
+ dev_info(dev, "registered SEV device\n");
+
return 0;
}
@@ -288,8 +285,8 @@ static int sev_init(struct psp_device *psp)
static void sev_exit(struct psp_device *psp)
{
- if (psp->sev_misc)
- misc_deregister(psp->sev_misc);
+ if (psp_misc_dev)
+ misc_deregister(psp_misc_dev);
}
int psp_dev_init(struct sp_device *sp)
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-12 14:08 ` Borislav Petkov
@ 2017-10-12 21:11 ` Brijesh Singh
2017-10-12 21:41 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 21:11 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/12/17 9:08 AM, Borislav Petkov wrote:
...
> Well, if you're going to have a global var, why not pull up the misc
> device instead?
>
> And mind you, I've moved out this assignments:
>
> + psp->sev_misc = psp_misc_dev;
> + init_waitqueue_head(&psp->sev_int_queue);
> + dev_info(dev, "registered SEV device\n");
>
> outside of the if-conditional as I'm assuming you want to do this for
> each psp device for which sev_ops_init() is called.
>
> Or am I wrong here?
I am OK with your patch except one minor issue highlighted below.
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 175cb3c3b8ef..d50aaa1ca75b 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -31,7 +31,7 @@
> #define DEVICE_NAME "sev"
>
> static DEFINE_MUTEX(sev_cmd_mutex);
> -static bool sev_fops_registered;
> +static struct miscdevice *psp_misc_dev;
>
> static struct psp_device *psp_alloc_struct(struct sp_device *sp)
> {
> @@ -242,7 +242,6 @@ EXPORT_SYMBOL_GPL(sev_guest_df_flush);
> static int sev_ops_init(struct psp_device *psp)
> {
> struct device *dev = psp->dev;
> - struct miscdevice *misc;
> int ret;
>
> /*
> @@ -252,26 +251,24 @@ 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_fops_registered) {
> -
> - misc = devm_kzalloc(dev, sizeof(*misc), GFP_KERNEL);
> - if (!misc)
> + if (!psp_misc_dev) {
> + psp_misc_dev = devm_kzalloc(dev, sizeof(struct miscdevice), GFP_KERNEL);
> + if (!psp_misc_dev)
> return -ENOMEM;
>
> - misc->minor = MISC_DYNAMIC_MINOR;
> - misc->name = DEVICE_NAME;
> - misc->fops = &sev_fops;
> + psp_misc_dev->minor = MISC_DYNAMIC_MINOR;
> + psp_misc_dev->name = DEVICE_NAME;
> + psp_misc_dev->fops = &sev_fops;
>
> - ret = misc_register(misc);
> + ret = misc_register(psp_misc_dev);
> if (ret)
> return ret;
> -
> - sev_fops_registered = true;
> - psp->sev_misc = misc;
> - init_waitqueue_head(&psp->sev_int_queue);
> - dev_info(dev, "registered SEV device\n");
> }
>
> + psp->sev_misc = psp_misc_dev;
> + init_waitqueue_head(&psp->sev_int_queue);
> + dev_info(dev, "registered SEV device\n");
> +
> return 0;
> }
>
> @@ -288,8 +285,8 @@ static int sev_init(struct psp_device *psp)
>
> static void sev_exit(struct psp_device *psp)
> {
> - if (psp->sev_misc)
> - misc_deregister(psp->sev_misc);
> + if (psp_misc_dev)
> + misc_deregister(psp_misc_dev);
The sev_exit() will be called for all the psp_device instance. we need
to set psp_misc_dev = NULL after deregistering the device.
if (psp_misc_dev) {
misc_deregister(psp_misc_dev);
psp_misc_dev = NULL;
}
> }
>
> int psp_dev_init(struct sp_device *sp)
>
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-12 21:11 ` Brijesh Singh
@ 2017-10-12 21:41 ` Borislav Petkov
2017-10-12 21:52 ` Brijesh Singh
0 siblings, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 21:41 UTC (permalink / raw)
To: Brijesh Singh
Cc: Paolo Bonzini, Radim Krčmář,
Herbert Xu, Gary Hook, Tom Lendacky, linux-crypto, kvm,
linux-kernel
On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
> The sev_exit() will be called for all the psp_device instance. we need
> to set psp_misc_dev = NULL after deregistering the device.
>
> if (psp_misc_dev) {
> misc_deregister(psp_misc_dev);
> psp_misc_dev = NULL;
Right, except we assign that misc device to every psp device:
psp->sev_misc = psp_misc_dev;
so the question now is, how do you want this to work: the misc device
should be destroyed after the last psp device is destroyed or how?
Because after the first:
psp_misc_dev = NULL;
the respective psp->sev_misc will still keep references to that device
but the device itself will be already deregistered. And that sounds
strange.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-12 21:41 ` Borislav Petkov
@ 2017-10-12 21:52 ` Brijesh Singh
2017-10-12 22:22 ` Borislav Petkov
0 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 21:52 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/12/17 4:41 PM, Borislav Petkov wrote:
> On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
>> The sev_exit() will be called for all the psp_device instance. we need
>> to set psp_misc_dev = NULL after deregistering the device.
>>
>> if (psp_misc_dev) {
>> misc_deregister(psp_misc_dev);
>> psp_misc_dev = NULL;
> Right, except we assign that misc device to every psp device:
>
> psp->sev_misc = psp_misc_dev;
>
> so the question now is, how do you want this to work: the misc device
> should be destroyed after the last psp device is destroyed or how?
We don't know when the last psp device is getting destroyed. Since we
are making the sev_misc_dev as a global variable then there is no
reason for 'sev_misc' field in the psp_device.
> Because after the first:
>
> psp_misc_dev = NULL;
>
> the respective psp->sev_misc will still keep references to that device
> but the device itself will be already deregistered. And that sounds
> strange.
See my above comment, I think the simplest solution is remove psp->sev_misc
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-12 21:52 ` Brijesh Singh
@ 2017-10-12 22:22 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 22: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 Thu, Oct 12, 2017 at 04:52:32PM -0500, Brijesh Singh wrote:
> See my above comment, I think the simplest solution is remove psp->sev_misc
Ok, so far so good.
But now you still need to track which is the last psp device and to call
misc_deregister() only when the last device exits. Because if you do
that for the first psp device as it is now, all the following devices
will see a deregistered misc device. And I don't think we want that.
You probably could do something with reference counting: Documentation/kref.txt
to track that and have the last device deregister the misc device.
Or have the "enclosing" sp-dev deregister the misc device when it is
exiting and when it is sure that there are no more psp devices...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-11 16:50 ` [Part2 PATCH v5.2 12.2/31] " Brijesh Singh
2017-10-12 14:08 ` Borislav Petkov
@ 2017-10-12 18:21 ` Borislav Petkov
2017-10-12 20:05 ` Brijesh Singh
1 sibling, 1 reply; 112+ messages in thread
From: Borislav Petkov @ 2017-10-12 18: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 Wed, Oct 11, 2017 at 11:50:30AM -0500, Brijesh Singh wrote:
> +static int sev_do_cmd(int cmd, void *data, int *psp_ret)
> +{
> + unsigned int phys_lsb, phys_msb;
> + struct psp_device *psp;
> + unsigned int reg, ret;
> + 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);
> +
> + ret = sev_wait_cmd_ioc(psp, ®);
Btw, that function returns 0 unconditionally. So you can make it return
void and...
> + if (ret)
> + goto unlock;
... remove this check and initialize ret to 0 at the beginning.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5.2 12.2/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support
2017-10-12 18:21 ` Borislav Petkov
@ 2017-10-12 20:05 ` Brijesh Singh
0 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-12 20:05 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/12/17 1:21 PM, Borislav Petkov wrote:
.....
> Btw, that function returns 0 unconditionally. So you can make it return
> void and...
Will do
>> + if (ret)
>> + goto unlock;
> ... remove this check and initialize ret to 0 at the beginning.
>
Will do
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 13/31] KVM: X86: Add CONFIG_KVM_AMD_SEV
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (11 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 12/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-13 16:44 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 14/31] KVM: SVM: Add sev module_param Brijesh Singh
` (15 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
The config option can be used to enable SEV support on AMD Processors.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 3ea624452f93..bedb204f71c9 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -79,6 +79,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] 112+ messages in thread* Re: [Part2 PATCH v5 13/31] KVM: X86: Add CONFIG_KVM_AMD_SEV
2017-10-04 13:13 ` [Part2 PATCH v5 13/31] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
@ 2017-10-13 16:44 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 16:44 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:54AM -0500, Brijesh Singh wrote:
> The config option can be used to enable SEV support on AMD Processors.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: x86@kernel.org
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> arch/x86/kvm/Kconfig | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 3ea624452f93..bedb204f71c9 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -79,6 +79,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
> --
Reviewed-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] 112+ messages in thread
* [Part2 PATCH v5 14/31] KVM: SVM: Add sev module_param
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (12 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 13/31] KVM: X86: Add CONFIG_KVM_AMD_SEV Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-13 16:46 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 15/31] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
` (14 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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>
---
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] 112+ messages in thread* Re: [Part2 PATCH v5 14/31] KVM: SVM: Add sev module_param
2017-10-04 13:13 ` [Part2 PATCH v5 14/31] KVM: SVM: Add sev module_param Brijesh Singh
@ 2017-10-13 16:46 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 16:46 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:55AM -0500, Brijesh Singh wrote:
> 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>
> ---
> 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);
> --
Nice!
Reviewed-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] 112+ messages in thread
* [Part2 PATCH v5 15/31] KVM: SVM: Reserve ASID range for SEV guest
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (13 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 14/31] KVM: SVM: Add sev module_param Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-13 16:58 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 16/31] KVM: Define SEV key management command id Brijesh Singh
` (13 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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
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..3244b8f88010 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 maximum number of encrypted guest supported: Fn8001_001F[ECX].
+ * [31:0]: Number of supported guest
+ */
+static __init void sev_hardware_setup(void)
+{
+ max_sev_asid = cpuid_ecx(0x8000001F);
+}
+
static __init int svm_hardware_setup(void)
{
int cpu;
@@ -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 = false;
+ } else {
+ sev_hardware_setup();
+ pr_info("SEV supported\n");
+ }
+ }
+
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] 112+ messages in thread* Re: [Part2 PATCH v5 15/31] KVM: SVM: Reserve ASID range for SEV guest
2017-10-04 13:13 ` [Part2 PATCH v5 15/31] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
@ 2017-10-13 16:58 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 16:58 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:56AM -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
> 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..3244b8f88010 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 maximum number of encrypted guest supported: Fn8001_001F[ECX].
> + * [31:0]: Number of supported guest
> + */
> +static __init void sev_hardware_setup(void)
> +{
> + max_sev_asid = cpuid_ecx(0x8000001F);
> +}
> +
> static __init int svm_hardware_setup(void)
> {
> int cpu;
> @@ -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 = false;
> + } else {
> + sev_hardware_setup();
> + pr_info("SEV supported\n");
> + }
> + }
Flip that logic:
---
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3244b8f88010..d4b62536e305 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1057,8 +1057,8 @@ static int avic_ga_log_notifier(u32 ga_tag)
}
/*
- * Get maximum number of encrypted guest supported: Fn8001_001F[ECX].
- * [31:0]: Number of supported guest
+ * Get the maximum number of encrypted guests:
+ * Fn8001_001F[ECX][31:0]: Number of supported guests.
*/
static __init void sev_hardware_setup(void)
{
@@ -1096,12 +1096,12 @@ static __init int svm_hardware_setup(void)
}
if (sev) {
- if (!boot_cpu_has(X86_FEATURE_SEV) ||
- !IS_ENABLED(CONFIG_KVM_AMD_SEV)) {
- sev = false;
- } else {
+ if (boot_cpu_has(X86_FEATURE_SEV) &&
+ IS_ENABLED(CONFIG_KVM_AMD_SEV)) {
sev_hardware_setup();
pr_info("SEV supported\n");
+ } else {
+ sev = false;
}
}
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 16/31] KVM: Define SEV key management command id
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (14 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 15/31] KVM: SVM: Reserve ASID range for SEV guest Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-13 18:54 ` Borislav Petkov
2017-10-14 10:06 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 17/31] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
` (12 subsequent siblings)
28 siblings, 2 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
Define Secure Encrypted Virtualization (SEV) key management command id
and structure. The command definition is available in SEV KM [1] spec
0.14 and Documentation/virtual/kvm/amd-memory-encryption.txt
[1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
.../virtual/kvm/amd-memory-encryption.txt | 191 +++++++++++++++++++++
include/uapi/linux/kvm.h | 79 +++++++++
2 files changed, 270 insertions(+)
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
index 26472b4cdbaf..8c79946b4d43 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.txt
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -36,3 +36,194 @@ 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 Key management for the SEV guest is handled by a separate processor known as
+the AMD Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a
+secure key management interface to perform common hypervisor activities such as
+encrypting bootstrap code, snapshot, migrating and debugging the guest. For
+more information, see SEV Key Management spec at
+
+http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
+
+KVM implements the following commands to support SEV guests common lifecycle
+events such as launching, running, snapshotting, migrating and decommissioning
+guests.
+
+1. KVM_SEV_INIT
+
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform
+context. In a typical workflow, this command should be the first command issued.
+
+2. KVM_SEV_LAUNCH_START
+
+Parameters: struct kvm_sev_launch_start (in/out)
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_START command is used for creating the memory encryption
+context. To create the encryption context, user must provide a guest policy,
+the owner's public Diffie-Hellman (PDH) key and session information.
+
+struct kvm_sev_launch_start {
+ /* if zero then firmware creates a new handle */
+ __u32 handle;
+
+ /* guest's policy */
+ __u32 policy;
+
+ /* userspace address pointing to the guest owner's PDH key */
+ __u64 dh_uaddr;
+ __u32 dh_len;
+
+ /* userspace address which points to the guest session information */
+ __u64 session_addr;
+ __u32 session_len;
+};
+
+On success, the 'handle' field contain a new handle and on error, a negative value.
+
+For more details, see SEV spec Section 6.2.
+
+3. KVM_SEV_LAUNCH_UPDATE_DATA
+
+Parameters (in): struct kvm_sev_launch_update_data
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting the memory region. It also
+calculates a measurement of the memory contents. The measurement is a signature
+of the memory contents that can be sent to the guest owner as an attestation
+that the memory was encrypted correctly by the firmware.
+
+struct kvm_sev_launch_update {
+ /* userspace address need to be encrypted (must be 16-byte aligned) */
+ __u64 uaddr;
+
+ /* length of the data to be encrypted (must be 16-byte aligned) */
+ __u32 len;
+};
+
+For more details, see SEV spec Section 6.3.
+
+4. KVM_SEV_LAUNCH_MEASURE
+
+Parameters (in): struct kvm_sev_launch_measure
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement
+of the data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA. The guest owner
+may wait to provide the guest with confidential information until it can
+verify the measurement. Since the guest owner knows the initial contents
+of the guest at boot, the measurement can be verified by comparing it to
+what the guest owner expects.
+
+struct kvm_sev_launch_measure {
+ /* where to copy the measurement */
+ __u64 uaddr;
+
+ /* length of measurement blob */
+ __u32 len;
+};
+
+For more details on the measurement verification flow, see SEV spec Section 6.4
+
+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 {
+ /* guest handle */
+ __u32 handle;
+
+ /* guest policy */
+ __u32 policy;
+
+ /* guest state (see below) */
+ __u8 state;
+};
+
+SEV guest state:
+
+enum {
+ SEV_STATE_INVALID = 0;
+ SEV_STATE_LAUNCHING, /* guest is currently being launched */
+ SEV_STATE_SECRET, /* guest is being launched and ready to accept the ciphertext data */
+ SEV_STATE_RUNNING, /* guest is fully launched and running */
+ SEV_STATE_RECEIVING, /* guest is being migrated in from another SEV machine */
+ SEV_STATE_SENDING /* guest is getting migrated out to another SEV machine */
+};
+
+7. KVM_SEV_DBG_DECRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_DEBUG_DECRYPT command can be used by the hypervisor to request the
+firmware to decrypt the data at the given memory region.
+
+struct kvm_sev_dbg {
+ /* userspace address of data to decrypt */
+ __u64 src_uaddr;
+ /* userspace address of destination */
+ __u64 dst_uaddr;
+
+ /* length of memory region to decrypt */
+ __u32 len;
+};
+
+The command returns an error if guest policy does not allow debugging.
+
+8. KVM_SEV_DBG_ENCRYPT
+
+Parameters (in): struct kvm_sev_dbg
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_DEBUG_ENCRYPT command can be used by the hypervisor to request the
+firmware to encrypt the data at the given memory region.
+
+struct kvm_sev_dbg {
+ /* userspace address of data to encrypt */
+ __u64 src_uaddr;
+ /* userspace address of destination */
+ __u64 dst_uaddr;
+
+ /* length of memory region to encrypt */
+ __u32 len;
+};
+
+The command returns an error if guest policy does not allow debugging.
+
+9. KVM_SEV_LAUNCH_SECRET
+
+Parameters (in): struct kvm_sev_launch_secret
+Returns: 0 on success, -negative on error
+
+The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject a secret
+data after the measurement has been validated by the guest owner.
+
+struct kvm_sev_launch_secret {
+ /* userspace address containing the packet header */
+ __u64 hdr_uaddr;
+ __u32 hdr_len;
+
+ /* the guest memory region where the secret should be injected */
+ __u64 guest_uaddr;
+ __u32 guest_len;
+
+ /* the hypervisor memory region which contains the secret */
+ __u64 trans_uaddr;
+ __u32 trans_len;
+};
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index d595d3970390..115c75156711 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1368,6 +1368,85 @@ struct kvm_enc_region {
struct kvm_enc_region)
#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
struct kvm_enc_region)
+/* Secure Encrypted Virtualization command */
+enum sev_cmd_id {
+ /* Guest initialization commands */
+ 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)
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 16/31] KVM: Define SEV key management command id
2017-10-04 13:13 ` [Part2 PATCH v5 16/31] KVM: Define SEV key management command id Brijesh Singh
@ 2017-10-13 18:54 ` Borislav Petkov
2017-10-14 10:06 ` Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-13 18:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:57AM -0500, Brijesh Singh wrote:
> Define Secure Encrypted Virtualization (SEV) key management command id
> and structure. The command definition is available in SEV KM [1] spec
> 0.14 and Documentation/virtual/kvm/amd-memory-encryption.txt
>
> [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
>
> Cc: Thomas Gleixner <tglx@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 | 191 +++++++++++++++++++++
> include/uapi/linux/kvm.h | 79 +++++++++
> 2 files changed, 270 insertions(+)
Just formatting fixes:
---
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.txt b/Documentation/virtual/kvm/amd-memory-encryption.txt
index 8c79946b4d43..1ec5517f2948 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.txt
+++ b/Documentation/virtual/kvm/amd-memory-encryption.txt
@@ -39,17 +39,16 @@ defined in the CPUID 0x8000001f[ecx] field.
SEV Key Management
------------------
-The Key management for the SEV guest is handled by a separate processor known as
-the AMD Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a
-secure key management interface to perform common hypervisor activities such as
-encrypting bootstrap code, snapshot, migrating and debugging the guest. For
-more information, see SEV Key Management spec at
+The SEV guest key management is handled by a separate processor called the AMD
+Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a secure
+key management interface to perform common hypervisor activities such as
+encrypting bootstrap code, snapshot, migrating and debugging the guest. For more
+information, see the SEV Key Management spec:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
-KVM implements the following commands to support SEV guests common lifecycle
-events such as launching, running, snapshotting, migrating and decommissioning
-guests.
+KVM implements the following commands to support common lifecycle events of SEV
+guests, such as launching, running, snapshotting, migrating and decommissioning.
1. KVM_SEV_INIT
@@ -68,22 +67,17 @@ context. To create the encryption context, user must provide a guest policy,
the owner's public Diffie-Hellman (PDH) key and session information.
struct kvm_sev_launch_start {
- /* if zero then firmware creates a new handle */
- __u32 handle;
+ __u32 handle; /* if zero then firmware creates a new handle */
+ __u32 policy; /* guest's policy */
- /* guest's policy */
- __u32 policy;
-
- /* userspace address pointing to the guest owner's PDH key */
- __u64 dh_uaddr;
+ __u64 dh_uaddr; /* userspace address pointing to the guest owner's PDH key */
__u32 dh_len;
- /* userspace address which points to the guest session information */
- __u64 session_addr;
+ __u64 session_addr; /* userspace address which points to the guest session information */
__u32 session_len;
};
-On success, the 'handle' field contain a new handle and on error, a negative value.
+On success, the 'handle' field contains a new handle and on error, a negative value.
For more details, see SEV spec Section 6.2.
@@ -92,17 +86,14 @@ For more details, see SEV spec Section 6.2.
Parameters (in): struct kvm_sev_launch_update_data
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting the memory region. It also
+The KVM_SEV_LAUNCH_UPDATE_DATA is used for encrypting a memory region. It also
calculates a measurement of the memory contents. The measurement is a signature
of the memory contents that can be sent to the guest owner as an attestation
that the memory was encrypted correctly by the firmware.
struct kvm_sev_launch_update {
- /* userspace address need to be encrypted (must be 16-byte aligned) */
- __u64 uaddr;
-
- /* length of the data to be encrypted (must be 16-byte aligned) */
- __u32 len;
+ __u64 uaddr; /* userspace address to be encrypted (must be 16-byte aligned) */
+ __u32 len; /* length of the data to be encrypted (must be 16-byte aligned) */
};
For more details, see SEV spec Section 6.3.
@@ -112,22 +103,19 @@ For more details, see SEV spec Section 6.3.
Parameters (in): struct kvm_sev_launch_measure
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement
-of the data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA. The guest owner
-may wait to provide the guest with confidential information until it can
-verify the measurement. Since the guest owner knows the initial contents
-of the guest at boot, the measurement can be verified by comparing it to
-what the guest owner expects.
+The KVM_SEV_LAUNCH_MEASURE command is used to retrieve the measurement of the
+data encrypted by the KVM_SEV_LAUNCH_UPDATE_DATA command. The guest owner may
+wait to provide the guest with confidential information until it can verify the
+measurement. Since the guest owner knows the initial contents of the guest at
+boot, the measurement can be verified by comparing it to what the guest owner
+expects.
struct kvm_sev_launch_measure {
- /* where to copy the measurement */
- __u64 uaddr;
-
- /* length of measurement blob */
- __u32 len;
+ __u64 uaddr; /* where to copy the measurement */
+ __u32 len; /* length of measurement blob */
};
-For more details on the measurement verification flow, see SEV spec Section 6.4
+For more details on the measurement verification flow, see SEV spec Section 6.4.
5. KVM_SEV_LAUNCH_FINISH
@@ -145,14 +133,9 @@ The KVM_SEV_GUEST_STATUS command is used to retrieve status information about a
SEV-enabled guest.
struct kvm_sev_guest_status {
- /* guest handle */
- __u32 handle;
-
- /* guest policy */
- __u32 policy;
-
- /* guest state (see below) */
- __u8 state;
+ __u32 handle; /* guest handle */
+ __u32 policy; /* guest policy */
+ __u8 state; /* guest state (see enum below) */
};
SEV guest state:
@@ -175,16 +158,12 @@ The KVM_SEV_DEBUG_DECRYPT command can be used by the hypervisor to request the
firmware to decrypt the data at the given memory region.
struct kvm_sev_dbg {
- /* userspace address of data to decrypt */
- __u64 src_uaddr;
- /* userspace address of destination */
- __u64 dst_uaddr;
-
- /* length of memory region to decrypt */
- __u32 len;
+ __u64 src_uaddr; /* userspace address of data to decrypt */
+ __u64 dst_uaddr; /* userspace address of destination */
+ __u32 len; /* length of memory region to decrypt */
};
-The command returns an error if guest policy does not allow debugging.
+The command returns an error if the guest policy does not allow debugging.
8. KVM_SEV_DBG_ENCRYPT
@@ -195,35 +174,28 @@ The KVM_SEV_DEBUG_ENCRYPT command can be used by the hypervisor to request the
firmware to encrypt the data at the given memory region.
struct kvm_sev_dbg {
- /* userspace address of data to encrypt */
- __u64 src_uaddr;
- /* userspace address of destination */
- __u64 dst_uaddr;
-
- /* length of memory region to encrypt */
- __u32 len;
+ __u64 src_uaddr; /* userspace address of data to encrypt */
+ __u64 dst_uaddr; /* userspace address of destination */
+ __u32 len; /* length of memory region to encrypt */
};
-The command returns an error if guest policy does not allow debugging.
+The command returns an error if the guest policy does not allow debugging.
9. KVM_SEV_LAUNCH_SECRET
Parameters (in): struct kvm_sev_launch_secret
Returns: 0 on success, -negative on error
-The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject a secret
+The KVM_SEV_LAUNCH_SECRET command can be used by the hypervisor to inject secret
data after the measurement has been validated by the guest owner.
struct kvm_sev_launch_secret {
- /* userspace address containing the packet header */
- __u64 hdr_uaddr;
+ __u64 hdr_uaddr; /* userspace address containing the packet header */
__u32 hdr_len;
- /* the guest memory region where the secret should be injected */
- __u64 guest_uaddr;
+ __u64 guest_uaddr; /* the guest memory region where the secret should be injected */
__u32 guest_len;
- /* the hypervisor memory region which contains the secret */
- __u64 trans_uaddr;
+ __u64 trans_uaddr; /* the hypervisor memory region which contains the secret */
__u32 trans_len;
};
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 115c75156711..d35fde050f3a 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1364,10 +1364,9 @@ struct kvm_enc_region {
__u64 size;
};
-#define KVM_MEMORY_ENCRYPT_REGISTER_REGION _IOR(KVMIO, 0xbb,\
- struct kvm_enc_region)
-#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc,\
- struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_REGISTER_REGION _IOR(KVMIO, 0xbb, struct kvm_enc_region)
+#define KVM_MEMORY_ENCRYPT_UNREGISTER_REGION _IOR(KVMIO, 0xbc, struct kvm_enc_region)
+
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
/* Guest initialization commands */
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 16/31] KVM: Define SEV key management command id
2017-10-04 13:13 ` [Part2 PATCH v5 16/31] KVM: Define SEV key management command id Brijesh Singh
2017-10-13 18:54 ` Borislav Petkov
@ 2017-10-14 10:06 ` Borislav Petkov
1 sibling, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-14 10:06 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:57AM -0500, Brijesh Singh wrote:
> Define Secure Encrypted Virtualization (SEV) key management command id
> and structure. The command definition is available in SEV KM [1] spec
> 0.14 and Documentation/virtual/kvm/amd-memory-encryption.txt
>
> [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
Btw, that footnote is just silly - just do:
"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."
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 17/31] KVM: SVM: Add KVM_SEV_INIT command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (15 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 16/31] KVM: Define SEV key management command id Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-14 9:21 ` Borislav Petkov
2017-10-04 13:13 ` [Part2 PATCH v5 18/31] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
` (11 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 189 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 195 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 20fba8bfa727..6bd49e80a16d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -747,6 +747,11 @@ enum kvm_irqchip_mode {
KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */
};
+struct kvm_sev_info {
+ bool active; /* SEV enabled guest */
+ unsigned int asid; /* ASID used for this guest */
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
@@ -834,6 +839,8 @@ struct kvm_arch {
bool x2apic_format;
bool x2apic_broadcast_quirk_disabled;
+
+ struct kvm_sev_info sev_info;
};
struct kvm_vm_stat {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3244b8f88010..7f3179555a57 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,45 @@ static __init int svm_hardware_setup(void)
return r;
}
+static int sev_platform_get_state(int *state, int *error)
+{
+ int ret;
+ struct sev_data_status *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_platform_status(data, error);
+ if (!ret)
+ *state = data->state;
+
+ pr_info_once("SEV firmware major %d minor %d build %d\n",
+ data->api_major, data->api_minor, data->build);
+
+ kfree(data);
+ return ret;
+}
+
+static __exit void sev_hardware_unsetup(void)
+{
+ int state;
+
+ sev_platform_get_state(&state, NULL);
+
+ if (state != SEV_STATE_UNINIT)
+ sev_platform_shutdown(NULL);
+
+ kfree(sev_asid_bitmap);
+}
+
static __exit void svm_hardware_unsetup(void)
{
int cpu;
+ if (svm_sev_enabled())
+ sev_hardware_unsetup();
+
for_each_possible_cpu(cpu)
svm_cpu_uninit(cpu);
@@ -1361,6 +1416,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 +1501,38 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
return 0;
}
+static void sev_firmware_exit(void)
+{
+ int state;
+
+ sev_platform_get_state(&state, NULL);
+
+ if (state == SEV_STATE_INIT)
+ sev_platform_shutdown(NULL);
+}
+
+static void sev_asid_free(struct kvm *kvm)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ int pos, asid;
+
+ if (!svm_sev_enabled())
+ return;
+
+ asid = sev->asid;
+ pos = asid - 1;
+ clear_bit(pos, sev_asid_bitmap);
+}
+
+static void sev_vm_destroy(struct kvm *kvm)
+{
+ if (!sev_guest(kvm))
+ return;
+
+ sev_firmware_exit();
+ sev_asid_free(kvm);
+}
+
static void avic_vm_destroy(struct kvm *kvm)
{
unsigned long flags;
@@ -1461,6 +1551,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 +5523,95 @@ static void svm_setup_mce(struct kvm_vcpu *vcpu)
vcpu->arch.mcg_cap &= 0x1ff;
}
+static int sev_asid_new(void)
+{
+ int pos;
+
+ if (!svm_sev_enabled())
+ return -EINVAL;
+
+ pos = find_first_zero_bit(sev_asid_bitmap, max_sev_asid);
+ if (pos >= max_sev_asid)
+ return -EBUSY;
+
+ set_bit(pos, sev_asid_bitmap);
+ return pos + 1;
+}
+
+static int sev_firmware_init(struct kvm *kvm, int *error)
+{
+ int ret, state = 0;
+
+ ret = sev_platform_get_state(&state, error);
+ if (ret)
+ return ret;
+
+ /* If SEV firmware is in uninitialized state, lets initialize it. */
+ if (state == SEV_STATE_UNINIT) {
+ struct sev_data_init *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = sev_platform_init(data, error);
+ kfree(data);
+ }
+
+ return ret;
+}
+
+static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ int asid, ret;
+
+ ret = sev_firmware_init(kvm, &argp->error);
+ if (ret)
+ return ret;
+
+ ret = -EBUSY;
+ asid = sev_asid_new();
+ if (asid < 0)
+ goto e_shutdown;
+
+ sev->active = true;
+ sev->asid = asid;
+ return 0;
+
+e_shutdown:
+ sev_firmware_exit();
+ return ret;
+}
+
+static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
+{
+ struct kvm_sev_cmd sev_cmd;
+ int r = -ENOTTY;
+
+ if (!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:
+ break;
+ }
+
+ mutex_unlock(&kvm->lock);
+ if (copy_to_user(argp, &sev_cmd, sizeof(struct kvm_sev_cmd)))
+ r = -EFAULT;
+ return r;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -5443,7 +5628,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 +5722,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] 112+ messages in thread* Re: [Part2 PATCH v5 17/31] KVM: SVM: Add KVM_SEV_INIT command
2017-10-04 13:13 ` [Part2 PATCH v5 17/31] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
@ 2017-10-14 9:21 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-14 9:21 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:58AM -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 | 189 +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 195 insertions(+), 1 deletion(-)
Just minor cleanups. With those applied:
Reviewed-by: Borislav Petkov <bp@suse.de>
---
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 26380627e7f9..7b3b199e15a1 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1189,8 +1189,8 @@ static __init int svm_hardware_setup(void)
static int sev_platform_get_state(int *state, int *error)
{
- int ret;
struct sev_data_status *data;
+ int ret;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
@@ -1201,7 +1201,7 @@ static int sev_platform_get_state(int *state, int *error)
*state = data->state;
pr_info_once("SEV firmware major %d minor %d build %d\n",
- data->api_major, data->api_minor, data->build);
+ data->api_major, data->api_minor, data->build);
kfree(data);
return ret;
@@ -5577,6 +5577,7 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
sev->active = true;
sev->asid = asid;
+
return 0;
e_shutdown:
@@ -5598,17 +5599,19 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
mutex_lock(&kvm->lock);
switch (sev_cmd.id) {
- case KVM_SEV_INIT: {
+ case KVM_SEV_INIT:
r = sev_guest_init(kvm, &sev_cmd);
break;
- }
+
default:
break;
}
mutex_unlock(&kvm->lock);
+
if (copy_to_user(argp, &sev_cmd, sizeof(struct kvm_sev_cmd)))
r = -EFAULT;
+
return r;
}
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 18/31] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (16 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 17/31] KVM: SVM: Add KVM_SEV_INIT command Brijesh Singh
@ 2017-10-04 13:13 ` Brijesh Singh
2017-10-14 9:27 ` Borislav Petkov
2017-10-04 13:14 ` [Part2 PATCH v5 19/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
` (10 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:13 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
SEV hardware uses ASIDs to associate memory encryption key with the
guest VM. During the guest creation time, SEV VM use SEV_CMD_ACTIVATE
command to bind a particular ASID to the guest. Lets make sure that the
VMCB is programmed with the bound ASID before a VMRUN.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7f3179555a57..a1388e74149f 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;
@@ -1514,7 +1535,8 @@ static void sev_firmware_exit(void)
static void sev_asid_free(struct kvm *kvm)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
- int pos, asid;
+ struct svm_cpu_data *sd;
+ int pos, asid, cpu;
if (!svm_sev_enabled())
return;
@@ -1522,6 +1544,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)
@@ -4456,12 +4483,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] 112+ messages in thread* Re: [Part2 PATCH v5 18/31] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled
2017-10-04 13:13 ` [Part2 PATCH v5 18/31] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
@ 2017-10-14 9:27 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-14 9:27 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
On Wed, Oct 04, 2017 at 08:13:59AM -0500, Brijesh Singh wrote:
> SEV hardware uses ASIDs to associate memory encryption key with the
> guest VM. During the guest creation time, SEV VM use SEV_CMD_ACTIVATE
> command to bind a particular ASID to the guest. Lets make sure that the
> VMCB is programmed with the bound ASID before a VMRUN.
Some minor corrections:
"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>
> ---
> arch/x86/kvm/svm.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 56 insertions(+), 2 deletions(-)
With that:
Reviewed-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] 112+ messages in thread
* [Part2 PATCH v5 19/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (17 preceding siblings ...)
2017-10-04 13:13 ` [Part2 PATCH v5 18/31] KVM: SVM: VMRUN should use assosiated ASID when SEV is enabled Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-14 10:08 ` Borislav Petkov
2017-10-04 13:14 ` [Part2 PATCH v5 20/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
` (9 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
The KVM_SEV_LAUNCH_START command is used to create a memory encryption
context within the SEV firmware. In order to create the memory encryption
context, the guest owner's 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 | 181 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6bd49e80a16d..7453ef7cb487 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -750,6 +750,8 @@ enum kvm_irqchip_mode {
struct kvm_sev_info {
bool active; /* SEV enabled guest */
unsigned int asid; /* ASID used for this guest */
+ unsigned int handle; /* SEV firmware handle */
+ int fd; /* SEV device fd */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a1388e74149f..c599a87810af 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1551,11 +1551,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_firmware_exit();
sev_asid_free(kvm);
}
@@ -5638,6 +5672,149 @@ 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 void *copy_user_blob(u64 __user uaddr, u32 len)
+{
+ void *data;
+
+ if (!uaddr || !len)
+ return ERR_PTR(-EINVAL);
+
+ /* verify that blob length does not exceed our limit */
+ if (len > SEV_FW_BLOB_MAX_SIZE)
+ return ERR_PTR(-EINVAL);
+
+ data = kmalloc(len, GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
+ goto e_free;
+
+ return data;
+
+e_free:
+ kfree(data);
+ return ERR_PTR(-EFAULT);
+}
+
+static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_start *start;
+ struct kvm_sev_launch_start params;
+ void *dh_blob, *session_blob;
+ int *error = &argp->error;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_start)))
+ return -EFAULT;
+
+ start = kzalloc(sizeof(*start), GFP_KERNEL);
+ if (!start)
+ return -ENOMEM;
+
+ dh_blob = NULL;
+ if (params.dh_uaddr) {
+ dh_blob = copy_user_blob(params.dh_uaddr, params.dh_len);
+ if (IS_ERR(dh_blob)) {
+ ret = PTR_ERR(dh_blob);
+ goto e_free;
+ }
+
+ start->dh_cert_address = __sme_set(__pa(dh_blob));
+ start->dh_cert_len = params.dh_len;
+ }
+
+ session_blob = NULL;
+ if (params.session_uaddr) {
+ dh_blob = copy_user_blob(params.session_uaddr, params.session_len);
+ if (IS_ERR(session_blob)) {
+ ret = PTR_ERR(session_blob);
+ goto e_free_dh;
+ }
+
+ start->session_address = __sme_set(__pa(session_blob));
+ start->session_len = params.session_len;
+ }
+
+ start->handle = params.handle;
+ start->policy = params.policy;
+
+ /* create memory encryption context */
+ ret = sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
+ if (ret)
+ goto e_free_session;
+
+ /* 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, ¶ms,
+ sizeof(struct kvm_sev_launch_start))) {
+ 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;
@@ -5656,6 +5833,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_guest_init(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_START: {
+ r = sev_launch_start(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 19/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command
2017-10-04 13:14 ` [Part2 PATCH v5 19/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
@ 2017-10-14 10:08 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-14 10:08 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
On Wed, Oct 04, 2017 at 08:14:00AM -0500, Brijesh Singh wrote:
> The KVM_SEV_LAUNCH_START command is used to create a memory encryption
> context within the SEV firmware. In order to create the memory encryption
> context, the guest owner's 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.
Minor cleanups:
"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."
Also, you can avoid the copy_user_blob() duplication by exporting the
version in psp-dev.c. Rest is minor cleanups.
---
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 55a4b7b9945c..a0106f31a5a7 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5713,31 +5713,6 @@ static int sev_issue_cmd(int fd, int id, void *data, int *error)
return ret;
}
-static void *copy_user_blob(u64 __user uaddr, u32 len)
-{
- void *data;
-
- if (!uaddr || !len)
- return ERR_PTR(-EINVAL);
-
- /* verify that blob length does not exceed our limit */
- if (len > SEV_FW_BLOB_MAX_SIZE)
- return ERR_PTR(-EINVAL);
-
- data = kmalloc(len, GFP_KERNEL);
- if (!data)
- return ERR_PTR(-ENOMEM);
-
- if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
- goto e_free;
-
- return data;
-
-e_free:
- kfree(data);
- return ERR_PTR(-EFAULT);
-}
-
static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
@@ -5750,8 +5725,7 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
if (!sev_guest(kvm))
return -ENOTTY;
- if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
- sizeof(struct kvm_sev_launch_start)))
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, sizeof(params)))
return -EFAULT;
start = kzalloc(sizeof(*start), GFP_KERNEL);
@@ -5760,7 +5734,7 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
dh_blob = NULL;
if (params.dh_uaddr) {
- dh_blob = copy_user_blob(params.dh_uaddr, params.dh_len);
+ 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;
@@ -5772,7 +5746,7 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
session_blob = NULL;
if (params.session_uaddr) {
- dh_blob = copy_user_blob(params.session_uaddr, params.session_len);
+ 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;
@@ -5797,8 +5771,8 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
/* return handle to userspace */
params.handle = start->handle;
- if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
- sizeof(struct kvm_sev_launch_start))) {
+ ret = copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms, sizeof(params));
+ if (ret) {
sev_unbind_asid(kvm, start->handle);
ret = -EFAULT;
goto e_free_session;
@@ -5834,10 +5808,9 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_guest_init(kvm, &sev_cmd);
break;
- case KVM_SEV_LAUNCH_START: {
+ case KVM_SEV_LAUNCH_START:
r = sev_launch_start(kvm, &sev_cmd);
break;
- }
default:
break;
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 331d028f9445..676abc233833 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -377,7 +377,7 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
return ret;
}
-static void *copy_user_blob(u64 __user uaddr, u32 len)
+void *psp_copy_user_blob(u64 __user uaddr, u32 len)
{
void *data;
@@ -392,7 +392,7 @@ static void *copy_user_blob(u64 __user uaddr, u32 len)
if (!data)
return ERR_PTR(-ENOMEM);
- if (copy_from_user(data, (void __user *)uaddr, len))
+ if (copy_from_user(data, (void __user *)(uintptr_t)uaddr, len))
goto e_free;
return data;
@@ -401,6 +401,7 @@ static void *copy_user_blob(u64 __user uaddr, u32 len)
kfree(data);
return ERR_PTR(-EFAULT);
}
+EXPORT_SYMBOL_GPL(psp_copy_user_blob);
static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
{
@@ -417,7 +418,7 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
return -ENOMEM;
/* copy PEK certificate blobs from userspace */
- pek_blob = copy_user_blob(input.pek_cert_address, input.pek_cert_len);
+ 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;
@@ -427,7 +428,7 @@ static int sev_ioctl_pek_cert_import(struct sev_issue_cmd *argp)
data->pek_cert_len = input.pek_cert_len;
/* copy PEK certificate blobs from userspace */
- oca_blob = copy_user_blob(input.oca_cert_address, input.oca_cert_len);
+ 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;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 17cd13e2bbe4..1bfa4f3a71cc 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -638,6 +638,7 @@ int sev_guest_df_flush(int *error);
* -%EIO if the sev returned a non-zero return code
*/
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 */
@@ -667,6 +668,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__ */
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 20/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (18 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 19/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_START command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-14 14:59 ` Borislav Petkov
2017-10-04 13:14 ` [Part2 PATCH v5 21/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
` (8 subsequent siblings)
28 siblings, 1 reply; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 193 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 192 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7453ef7cb487..86006dcfe574 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -752,6 +752,7 @@ struct kvm_sev_info {
unsigned int asid; /* ASID used for this guest */
unsigned int handle; /* SEV firmware handle */
int fd; /* SEV device fd */
+ unsigned long locked; /* Number of pages locked */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index c599a87810af..0871d3ab9e6c 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)
{
@@ -1582,6 +1585,82 @@ 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, pinned, size;
+ unsigned long locked, lock_limit;
+ struct page **pages;
+ int first, last;
+
+ /* calculate number of pages */
+ first = (uaddr & PAGE_MASK) >> PAGE_SHIFT;
+ last = ((uaddr + ulen - 1) & PAGE_MASK) >> PAGE_SHIFT;
+ npages = (last - first + 1);
+
+ locked = sev->locked + npages;
+ lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+ if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
+ pr_err("locked(%lu) > lock_limit(%lu)\n", locked, lock_limit);
+ return NULL;
+ }
+
+ /* Avoid using vmalloc for smaller buffer */
+ size = npages * sizeof(struct page *);
+ if (size > PAGE_SIZE)
+ pages = vmalloc(size);
+ else
+ pages = kmalloc(size, GFP_KERNEL);
+
+ if (!pages)
+ return NULL;
+
+ /* pin the user virtual address */
+ pinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0, pages);
+ if (pinned != npages) {
+ pr_err("failed to lock %lu pages\n", npages);
+ goto err;
+ }
+
+ *n = npages;
+ sev->locked = locked;
+
+ return pages;
+err:
+ if (pinned > 0)
+ release_pages(pages, pinned, 0);
+
+ kvfree(pages);
+ return NULL;
+}
+
+static void sev_unpin_memory(struct kvm *kvm, struct page **pages,
+ unsigned long npages)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ release_pages(pages, npages, 0);
+ kvfree(pages);
+ sev->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;
@@ -5697,7 +5776,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;
@@ -5712,6 +5791,13 @@ static int sev_issue_cmd(int fd, int id, void *data, int *error)
return ret;
}
+static int sev_issue_cmd(struct kvm *kvm, int id, void *data, int *error)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+
+ return __sev_issue_cmd(sev->fd, id, data, error);
+}
+
static void *copy_user_blob(u64 __user uaddr, u32 len)
{
void *data;
@@ -5785,7 +5871,7 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
start->policy = params.policy;
/* create memory encryption context */
- ret = sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
+ ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_LAUNCH_START, start, error);
if (ret)
goto e_free_session;
@@ -5815,6 +5901,105 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int get_num_contig_pages(int idx, struct page **inpages,
+ unsigned long npages)
+{
+ int i = idx + 1, pages = 1;
+ unsigned long paddr, next_paddr;
+
+ /* find the number of contiguous pages starting from idx */
+ paddr = __sme_page_pa(inpages[idx]);
+ while (i < npages) {
+ next_paddr = __sme_page_pa(inpages[i++]);
+ if ((paddr + PAGE_SIZE) == next_paddr) {
+ pages++;
+ paddr = next_paddr;
+ continue;
+ }
+ break;
+ }
+
+ return pages;
+}
+
+static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ unsigned long vaddr, vaddr_end, next_vaddr, npages, size;
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct kvm_sev_launch_update_data params;
+ struct sev_data_launch_update_data *data;
+ struct page **inpages;
+ int i, ret, pages;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_update_data)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ vaddr = params.uaddr;
+ size = params.len;
+ vaddr_end = vaddr + size;
+
+ /* lock the user memory */
+ inpages = sev_pin_memory(kvm, vaddr, size, &npages, 1);
+ if (!inpages) {
+ ret = -ENOMEM;
+ goto e_free;
+ }
+
+ /*
+ * 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).
+ * Its possible that our cache may contain the data with C=0. Lets
+ * invalidate it so that we can get the recent contents after LAUNCH_UPDATE
+ * command completes.
+ */
+ sev_clflush_pages(inpages, npages);
+
+ for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i += pages) {
+ int offset, len;
+
+ /*
+ * since user buffer may not be page aligned, calculate the
+ * offset within the page.
+ */
+ offset = vaddr & (PAGE_SIZE - 1);
+
+ /* calculate the number of pages that can be encrypted in one go */
+ pages = get_num_contig_pages(i, inpages, npages);
+
+ len = min_t(size_t, ((pages * PAGE_SIZE) - offset), size);
+
+ data->handle = sev->handle;
+ data->len = len;
+ data->address = __sme_page_pa(inpages[i]) + offset;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_DATA, data, &argp->error);
+ if (ret)
+ goto e_unpin;
+
+ size -= len;
+ next_vaddr = vaddr + len;
+ }
+
+e_unpin:
+ /* content of memory is updated, mark pages dirty */
+ for (i = 0; i < npages; i++) {
+ set_page_dirty_lock(inpages[i]);
+ mark_page_accessed(inpages[i]);
+ }
+ /* unlock the user pages */
+ sev_unpin_memory(kvm, inpages, npages);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -5837,6 +6022,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_start(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_UPDATE_DATA: {
+ r = sev_launch_update_data(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [Part2 PATCH v5 20/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command
2017-10-04 13:14 ` [Part2 PATCH v5 20/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
@ 2017-10-14 14:59 ` Borislav Petkov
0 siblings, 0 replies; 112+ messages in thread
From: Borislav Petkov @ 2017-10-14 14:59 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, kvm, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
On Wed, Oct 04, 2017 at 08:14:01AM -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 | 193 +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 192 insertions(+), 2 deletions(-)
Just cleanups:
---
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0d4e33eec78c..2bbfcd4ab6bc 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -752,7 +752,7 @@ struct kvm_sev_info {
unsigned int asid; /* ASID used for this guest */
unsigned int handle; /* SEV firmware handle */
int fd; /* SEV device fd */
- unsigned long locked; /* Number of pages locked */
+ 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 41eeeb30b56d..989bc8a9936f 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1590,24 +1590,24 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
int write)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
- unsigned long npages, pinned, size;
+ unsigned long npages, npinned, size;
unsigned long locked, lock_limit;
struct page **pages;
int first, last;
- /* calculate number of pages */
+ /* Calculate number of pages. */
first = (uaddr & PAGE_MASK) >> PAGE_SHIFT;
last = ((uaddr + ulen - 1) & PAGE_MASK) >> PAGE_SHIFT;
npages = (last - first + 1);
- locked = sev->locked + npages;
+ locked = sev->pages_locked + npages;
lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
- pr_err("locked(%lu) > lock_limit(%lu)\n", locked, lock_limit);
+ pr_err("SEV: %lu locked pages exceed the lock limit of %lu.\n", locked, lock_limit);
return NULL;
}
- /* Avoid using vmalloc for smaller buffer */
+ /* Avoid using vmalloc for smaller buffers. */
size = npages * sizeof(struct page *);
if (size > PAGE_SIZE)
pages = vmalloc(size);
@@ -1617,20 +1617,21 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
if (!pages)
return NULL;
- /* pin the user virtual address */
- pinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0, pages);
- if (pinned != npages) {
- pr_err("failed to lock %lu pages\n", npages);
+ /* 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->locked = locked;
+ sev->pages_locked = locked;
return pages;
+
err:
- if (pinned > 0)
- release_pages(pages, pinned, 0);
+ if (npinned > 0)
+ release_pages(pages, npinned, 0);
kvfree(pages);
return NULL;
@@ -1643,7 +1644,7 @@ static void sev_unpin_memory(struct kvm *kvm, struct page **pages,
release_pages(pages, npages, 0);
kvfree(pages);
- sev->locked -= npages;
+ sev->pages_locked -= npages;
}
static void sev_clflush_pages(struct page *pages[], unsigned long npages)
@@ -5909,8 +5910,7 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
if (!sev_guest(kvm))
return -ENOTTY;
- if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
- sizeof(struct kvm_sev_launch_update_data)))
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, sizeof(params)))
return -EFAULT;
data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -5921,7 +5921,7 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
size = params.len;
vaddr_end = vaddr + size;
- /* lock the user memory */
+ /* Lock the user memory. */
inpages = sev_pin_memory(kvm, vaddr, size, &npages, 1);
if (!inpages) {
ret = -ENOMEM;
@@ -5931,9 +5931,8 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
/*
* 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).
- * Its possible that our cache may contain the data with C=0. Lets
- * invalidate it so that we can get the recent contents after LAUNCH_UPDATE
- * command completes.
+ * 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);
@@ -5941,12 +5940,12 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
int offset, len;
/*
- * since user buffer may not be page aligned, calculate the
- * offset within the page.
+ * 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 */
+ /* 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);
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related [flat|nested] 112+ messages in thread
* [Part2 PATCH v5 21/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (19 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 20/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 22/31] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
` (7 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0871d3ab9e6c..25bb3cd9b66a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6000,6 +6000,68 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_launch_measure(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_measure *data;
+ struct kvm_sev_launch_measure params;
+ void *blob;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_measure)))
+ return -EFAULT;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ blob = NULL;
+ if (params.uaddr) {
+ if (params.len > SEV_FW_BLOB_MAX_SIZE) {
+ ret = -EINVAL;
+ goto e_free;
+ }
+
+ 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);
+
+ /* copy the measurement to userspace */
+ if (blob &&
+ copy_to_user((void __user *)(uintptr_t)params.uaddr, blob, params.len)) {
+ ret = -EFAULT;
+ goto e_free_blob;
+ }
+
+ params.len = data->len;
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
+ sizeof(struct kvm_sev_launch_measure)))
+ ret = -EFAULT;
+
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6026,6 +6088,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_update_data(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_MEASURE: {
+ r = sev_launch_measure(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 22/31] KVM: SVM: Add support for SEV LAUNCH_FINISH command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (20 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 21/31] KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 23/31] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
` (6 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
The command is used for finializing the SEV guest launch process.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 25bb3cd9b66a..f42707fabc0a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6062,6 +6062,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;
@@ -6092,6 +6112,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_measure(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_FINISH: {
+ r = sev_launch_finish(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 23/31] KVM: SVM: Add support for SEV GUEST_STATUS command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (21 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 22/31] KVM: SVM: Add support for SEV LAUNCH_FINISH command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 24/31] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
` (5 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f42707fabc0a..693724c75e2d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6082,6 +6082,37 @@ static int sev_launch_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
return ret;
}
+static int sev_guest_status(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct kvm_sev_guest_status params;
+ struct sev_data_guest_status *data;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_GUEST_STATUS, data, &argp->error);
+ if (ret)
+ goto e_free;
+
+ params.policy = data->policy;
+ params.state = data->state;
+ params.handle = data->handle;
+
+ if (copy_to_user((void __user *)(uintptr_t)argp->data, ¶ms,
+ sizeof(struct kvm_sev_guest_status)))
+ ret = -EFAULT;
+e_free:
+ kfree(data);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6116,6 +6147,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_launch_finish(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_GUEST_STATUS: {
+ r = sev_guest_status(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 24/31] KVM: SVM: Add support for SEV DEBUG_DECRYPT command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (22 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 23/31] KVM: SVM: Add support for SEV GUEST_STATUS command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 25/31] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
` (4 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 181 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 181 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 693724c75e2d..373f6c34e006 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6113,6 +6113,183 @@ 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 PSP may write the memory region with different C-bit (e.g
+ * x86 cache may have a mapping with C=0 and PSP may write the same
+ * region with C=1) hence lets make sure we invalidate the caches
+ * 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(struct kvm_sev_dbg)))
+ return -EFAULT;
+
+ vaddr = debug.src_uaddr;
+ size = debug.len;
+ vaddr_end = vaddr + size;
+ dst_vaddr = debug.dst_uaddr;
+ dst_vaddr_end = dst_vaddr + size;
+
+ for (; vaddr < vaddr_end; vaddr = next_vaddr) {
+ int len, s_off, d_off;
+
+ /* lock userspace source and destination page */
+ src_p = sev_pin_memory(kvm, vaddr & PAGE_MASK, PAGE_SIZE, &n, 0);
+ if (!src_p)
+ return -EFAULT;
+
+ dst_p = sev_pin_memory(kvm, dst_vaddr & PAGE_MASK, PAGE_SIZE, &n, 1);
+ if (!dst_p) {
+ sev_unpin_memory(kvm, src_p, n);
+ return -EFAULT;
+ }
+
+ /*
+ * The PSP may write the memory region with different C-bit (e.g
+ * x86 cache may have a mapping with C=0 and PSP may write the same
+ * region with C=1) hence lets make sure we invalidate the caches
+ * so that we can see the recent contents after the command completion.
+ */
+ 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;
@@ -6151,6 +6328,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_guest_status(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_DBG_DECRYPT: {
+ r = sev_dbg_decrypt(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 25/31] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (23 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 24/31] KVM: SVM: Add support for SEV DEBUG_DECRYPT command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 26/31] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
` (3 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 115 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 373f6c34e006..2aa50b220163 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6212,6 +6212,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;
@@ -6265,11 +6358,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);
@@ -6290,6 +6391,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;
@@ -6332,6 +6438,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_dbg_decrypt(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_DBG_ENCRYPT: {
+ r = sev_dbg_encrypt(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 26/31] KVM: SVM: Add support for SEV LAUNCH_SECRET command
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (24 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 25/31] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 27/31] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
` (2 subsequent siblings)
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2aa50b220163..5ab81cc66333 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6396,6 +6396,75 @@ static int sev_dbg_encrypt(struct kvm *kvm, struct kvm_sev_cmd *argp)
return sev_dbg_crypt(kvm, argp, false);
}
+static int sev_launch_secret(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+ struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct sev_data_launch_secret *data;
+ struct kvm_sev_launch_secret params;
+ struct page **pages;
+ void *blob, *hdr;
+ unsigned long n;
+ int ret;
+
+ if (!sev_guest(kvm))
+ return -ENOTTY;
+
+ if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data,
+ sizeof(struct kvm_sev_launch_secret)))
+ return -EFAULT;
+
+ /* 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 = copy_user_blob(params.trans_uaddr, params.trans_len);
+ if (IS_ERR(blob)) {
+ ret = PTR_ERR(blob);
+ goto e_free;
+ }
+
+ data->trans_address = __psp_pa(blob);
+ data->trans_len = params.trans_len;
+
+ /* copy the packet header from userspace into a kernel buffer */
+ hdr = copy_user_blob(params.hdr_uaddr, params.hdr_len);
+ if (IS_ERR(hdr)) {
+ ret = PTR_ERR(hdr);
+ goto e_free_blob;
+ }
+ data->trans_address = __psp_pa(blob);
+ data->trans_len = params.trans_len;
+
+ data->handle = sev->handle;
+ ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_SECRET, data, &argp->error);
+
+ kfree(hdr);
+
+e_free_blob:
+ kfree(blob);
+e_free:
+ kfree(data);
+e_unpin_memory:
+ sev_unpin_memory(kvm, pages, n);
+ return ret;
+}
+
static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
{
struct kvm_sev_cmd sev_cmd;
@@ -6442,6 +6511,10 @@ static int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
r = sev_dbg_encrypt(kvm, &sev_cmd);
break;
}
+ case KVM_SEV_LAUNCH_SECRET: {
+ r = sev_launch_secret(kvm, &sev_cmd);
+ break;
+ }
default:
break;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 27/31] KVM: SVM: Pin guest memory when SEV is active
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (25 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 26/31] KVM: SVM: Add support for SEV LAUNCH_SECRET command Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 28/31] KVM: X86: Add memory encryption enabled ops Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 29/31] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 86006dcfe574..3195a8cc517d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -753,6 +753,7 @@ struct kvm_sev_info {
unsigned int handle; /* SEV firmware handle */
int fd; /* SEV device fd */
unsigned long locked; /* Number of pages locked */
+ struct list_head regions_list; /* list of registered regions */
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5ab81cc66333..daf7aa8ed2c7 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;
@@ -1661,13 +1669,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(®ion->list);
+ kfree(region);
+}
+
static void sev_vm_destroy(struct kvm *kvm)
{
struct kvm_sev_info *sev = &kvm->arch.sev_info;
+ struct list_head *head = &sev->regions_list;
+ struct list_head *pos, *q;
if (!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_firmware_exit();
sev_asid_free(kvm);
@@ -5744,6 +5781,7 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
sev->active = true;
sev->asid = asid;
+ INIT_LIST_HEAD(&sev->regions_list);
return 0;
e_shutdown:
@@ -6525,6 +6563,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, ®ion->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(®ion->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,
@@ -6637,6 +6747,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.setup_mce = svm_setup_mce,
.mem_enc_op = svm_mem_enc_op,
+ .mem_enc_register_region = svm_register_enc_region,
+ .mem_enc_unregister_region = svm_unregister_enc_region,
};
static int __init svm_init(void)
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 28/31] KVM: X86: Add memory encryption enabled ops
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (26 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 27/31] KVM: SVM: Pin guest memory when SEV is active Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
2017-10-04 13:14 ` [Part2 PATCH v5 29/31] KVM: SVM: Clear C-bit from the page fault address Brijesh Singh
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
Extend kvm_x86_ops to add mem_enc_enabled() ops. The ops can be used to
check if memory encryption is enabled for a given VCPU.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3195a8cc517d..cad9672fbe8c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1076,6 +1076,7 @@ struct kvm_x86_ops {
int (*mem_enc_op)(struct kvm *kvm, void __user *argp);
int (*mem_enc_register_region)(struct kvm *kvm, struct kvm_enc_region *argp);
int (*mem_enc_unregister_region)(struct kvm *kvm, struct kvm_enc_region *argp);
+ bool (*mem_enc_enabled)(struct kvm_vcpu *vcpu);
};
struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index daf7aa8ed2c7..5c2f5b15886c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6635,6 +6635,11 @@ static int svm_unregister_enc_region(struct kvm *kvm,
return 0;
}
+static bool mem_enc_enabled(struct kvm_vcpu *vcpu)
+{
+ return to_svm(vcpu)->vmcb->control.nested_ctl & SVM_NESTED_CTL_SEV_ENABLE;
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -6749,6 +6754,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.mem_enc_op = svm_mem_enc_op,
.mem_enc_register_region = svm_register_enc_region,
.mem_enc_unregister_region = svm_unregister_enc_region,
+ .mem_enc_enabled = mem_enc_enabled
};
static int __init svm_init(void)
--
2.9.5
^ permalink raw reply related [flat|nested] 112+ messages in thread* [Part2 PATCH v5 29/31] KVM: SVM: Clear C-bit from the page fault address
2017-10-04 13:13 [Part2 PATCH v5 00/31] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
` (27 preceding siblings ...)
2017-10-04 13:14 ` [Part2 PATCH v5 28/31] KVM: X86: Add memory encryption enabled ops Brijesh Singh
@ 2017-10-04 13:14 ` Brijesh Singh
28 siblings, 0 replies; 112+ messages in thread
From: Brijesh Singh @ 2017-10-04 13:14 UTC (permalink / raw)
To: x86, kvm, linux-kernel
Cc: Brijesh Singh, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Borislav Petkov, Tom Lendacky
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 5c2f5b15886c..a47981714433 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2439,7 +2439,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] 112+ messages in thread