From patchwork Mon Jan 10 06:04:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shirong Hao X-Patchwork-Id: 530966 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9316DC433F5 for ; Mon, 10 Jan 2022 06:05:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238865AbiAJGFG (ORCPT ); Mon, 10 Jan 2022 01:05:06 -0500 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:43061 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238861AbiAJGFE (ORCPT ); Mon, 10 Jan 2022 01:05:04 -0500 X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R581e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04407; MF=shirong@linux.alibaba.com; NM=1; PH=DS; RN=25; SR=0; TI=SMTPD_---0V1LvBNz_1641794698; Received: from localhost.localdomain(mailfrom:shirong@linux.alibaba.com fp:SMTPD_---0V1LvBNz_1641794698) by smtp.aliyun-inc.com(127.0.0.1); Mon, 10 Jan 2022 14:05:00 +0800 From: Shirong Hao To: pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, tglx@linutronix.de, mingo@redhat.co, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, brijesh.singh@amd.com, thomas.lendacky@amd.com, john.allen@amd.com, herbert@gondor.apana.org.au, davem@davemloft.net, srutherford@google.com, ashish.kalra@amd.com, natet@google.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, zhang.jia@linux.alibaba.com, Shirong Hao Subject: [PATCH 0/3] Allow guest to query AMD SEV(-ES) runtime attestation evidence Date: Mon, 10 Jan 2022 14:04:42 +0800 Message-Id: <20220110060445.549800-1-shirong@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org This patch series is provided to allow the guest application to query AMD SEV(-ES) runtime attestation evidence by communicating with the host service (Attestation Evidence Broker). The following is the design document. > Background Compared with SEV-SNP and Intel TDX, the runtime attestation of SEV(-ES) does NOT support guest-provided data included in the attestation report [1,2]. In addition, SEV(-ES) also does NOT support the dynamic measurement. During runtime, it can only generate static attestation report with the constant launch digest reflecting the initial measurement. Although SEV(-ES) has above limitations, its runtime attestation is still useful. When the SEV(-ES) guest is running, it can report the attestation report with fixed launch digest as a heartbeat for trusted healthy check. SEV(-ES) runtime attestation includes two participants: attester and verifier. - The attester running in a SEV(-ES) guest is responsible for collecting attestation evidence. - The verifier running in a trusted environment is responsible for verifying the attestation evidence provided by the attester. Note that the verifier can run on any platform even non-TEE. > SEV(-ES) Attestation Evidence Verifier uses the following SEV(-ES) certificate chains to verify the signature of the attestation report generated by the `ATTESTATION` command [2]: 1. certificate chain for device identity: ARK -> ASK -> CEK -> PEK -> report 2. certificate chain for platform owner identity: OCA -> PEK -> report - `foo -> bar` indicates using the public key of `foo` to verify the signature of `bar`. - ARK is the root of trust of AMD and OCA is the root of trust for platform owners. OCA has two ways: 1. Self-owned: The OCA Key Pair and self-signed OCA certificate are automatically generated by the SEV(-ES) firmware. 2. Externally-owned: External users use OCA Key Pair to generate self-signed OCA certificates in a trusted environment. Verifier needs to verify the attestation report with the certificate chain. ARK and ASK can be obtained directly from the AMD KDS server. CEK, PEK, OCA, and attestation report are related to the specific SEV(-ES) platform, therefore SEV(-ES) Attestation Evidence collected by attester should include attestation report (with the constant launch digest), PEK, CEK, and OCA certificate. | Contents of SEV(-ES) Attestation Evidence | SEV(-ES) firmware command | | :-: | :-: | | attestation report | ATTESTATION | | CEK | GET_ID | | OCA,PEK | PDH_CERT_EXPORT | > Query SEV(-ES) Attestation Evidence According to the official feedback[3], SEV(-ES) firmware APIs don't support query attestation report in SEV(-ES) guest and there is no plan to support it in the future. Instead, this capability will be available in SEV-SNP. In some scenarios, the guest application needs to query the attestation report to establish an attested channel with the remote peer. There are two approaches for a guest application to query an attestation evidence: - Hypercall approach - VSOCK approach Considering time and cost, we only need to implement one of them. - Hypercall approach SEV(-ES) guest exits to VMM using `hypercall` and then interacts with SEV firmware to query the components composing an attestation evidence, including attestation report, PEK, CEK, OCA certificate. To build an attestation evidence, the steps include: 1. The guest application requests a shared memory page, initiates a hypercall, and switches from the guest mode to the host mode. 2. In the host mode, KVM sends the `GET_ID, PDH_CERT_EXPORT, ATTESTATION` command requests to SEV firmware. 3. The shared memory page is filled with the data returned by the SEV firmware. 4. The guest application can obtain attestation evidence by reading the data in the shared memory. Although this method can meet our requirements, it requires a lot of modifications to the guest kernel and KVM. - VSOCK approach In the current implementation, QEMU provides the QMP interface "query-sev-attestation-report" to query the attestation report in the host. However, QEMU is not the only VMM. In order to support various VMM in different scenarios, it is necessary to design a general host service, such as attestation evidence Broker (AEB) to query attestation evidence from the host. The workflow of AEB is as followed: 1. The user-level application in the guest sends a request (including guest firmware handle) to AEB through VSOCK. 2. AEB requests to query attestation report, PEK, CEK, OCA certificate by calling multiple SEV firmware APIs (refer to the table above for specific API commands) and assembles these information into the attestation evidence. 3. AEB returns the attestation evidence to the application in the guest. To query the attestation report in host with AEB, we provides three patches to achieve the following two goals. 1. It is necessary to add a `SEV_GET_REPORT` interface in ccp driver so that AEB can execute `ioctl` on the `/dev/sev` device and then call the `SEV_GET_REPORT` interface to send the `ATTESTATION` command to the SEV firmware to query attestation report. 2. In order to obtain the guest handle required by the `ATTESTATION` command to the SEV firmware, a new hypercall needs to be added to the KVM. The application in the guest obtains the guest handle through this newly added hypercal, and then sends it to the AEB service through VSOCK. The AEB service uses the guest handle as the input parameter of the `ATTESTATION` command to interact with the SEV firmware. Note that hypercall is not the only way to obtain the guest handle. Actually the qmp interface `query-sev` can query the guest handle as well. However, as mentioned previously, qemu is not the only VMM. > Communication protocol Below is the communication protocol between the guest application and AEB. ```protobuf syntax = "proto3"; ... message RetrieveAttestationEvidenceSizeRequest{ uint32 guest_handle = 1; } message RetrieveAttestationEvidenceRequest{ uint32 guest_handle = 1; uint32 evidence_size = 2; } message RetrieveAttestationEvidenceSizeResponse{ uint32 error_code = 1; uint32 evidence_size = 2; } message RetrieveAttestationEvidenceResponse{ uint32 error_code = 1; uint32 evidence_size = 2; bytes evidence = 3; } service AEBService { rpc RetrieveAttestationEvidenceSize (RetrieveAttestationEvidenceSizeRequest) returns (RetrieveAttestationEvidenceSizeResponse); rpc RetrieveAttestationEvidence(RetrieveAttestationEvidenceRequest) returns (RetrieveAttestationEvidenceResponse); } ``` > Reference [1] https://www.amd.com/system/files/TechDocs/ 55766_SEV-KM_API_Specification.pdf [2] https://www.amd.com/system/files/TechDocs/56860.pdf [3] https://github.com/AMDESE/AMDSEV/issues/71#issuecomment-926118314 Shirong Hao (3): KVM: X86: Introduce KVM_HC_VM_HANDLE hypercall KVM/SVM: move the implementation of sev_get_attestation_report to ccp driver crypto: ccp: Implement SEV_GET_REPORT ioctl command arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/svm/sev.c | 49 +++------------------- arch/x86/kvm/svm/svm.c | 11 +++++ arch/x86/kvm/x86.c | 7 +++- drivers/crypto/ccp/sev-dev.c | 74 +++++++++++++++++++++++++++++++++ include/linux/psp-sev.h | 7 ++++ include/uapi/linux/kvm_para.h | 1 + include/uapi/linux/psp-sev.h | 17 ++++++++ 8 files changed, 123 insertions(+), 44 deletions(-)