From patchwork Mon Jan 20 21:31:13 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Melody Wang X-Patchwork-Id: 13945538 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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5BF15C0218B for ; Mon, 20 Jan 2025 22:00:24 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tZzo1-0006zr-Pm; Mon, 20 Jan 2025 16:59:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tZzRw-0002Dg-Bl for qemu-devel@nongnu.org; Mon, 20 Jan 2025 16:36:52 -0500 Received: from mail-mw2nam10on2049.outbound.protection.outlook.com ([40.107.94.49] helo=NAM10-MW2-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tZzRt-0002PY-MD for qemu-devel@nongnu.org; Mon, 20 Jan 2025 16:36:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nwH9GfUmLD07YcvKtBdUkWNw3wXLUVtcTkM/KZ+PLcyr0MZPv8zRYCbBITK1luPHMtd8vThoFvXUhby4i+hjjCFO+qx16ADcx40qv+E8VgVFlvd29M1dNp2wSAyOJnqiWx9/hZGH7Z79cTWhLh80jj4Xz/GM3VXOAeRkVcBRmjKhH7iPAkDOvPLqUYB2ERle4TtWLZNX17UPkMOwZ6Pv0XjUfHQtuCHUXN/pXU/6ciPH2bmWX/IYnzhgforTBUNdWCg29Svp3xo7JcgjOKQ8HYZZeoDZ/1uc7iB7xdM+zUaqCZUCu25YCq1zoLbHaolji/pAL6M1qz5/uRk/QaXyxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nkN0kETK4FYLVdivoNDUGZ0u0viRnxS05EHhYVLgfgg=; b=lzhYHrw0L3X1OCHaAPItVrhaY74qEV1sIifN2U36Fjm+a4aABuzCzUSGXYVXE/pWum9LkVGf2T/zluXMJHuL7bjB3NY0s+8fYkGPjvzIlvWGPclivTpD7q3fhS2+pDyfw4ju5v7G1wMBuLfCVU6JF2MZF8PTyLkl70bk/iFseUdOwqXlcmvP4iSXGO9aKEqt7ZeLID91wUKE5Z7zOdj72hOQ8p3L/I3bvyImiEon8XTJ6YOeKkp+qFuDmAcPKrHUqyXZj7JSnU5ky8c2QwMQ3GiXz9e5pbvDrfvRTInjB1RODG2kuYu2h+RsxlpfSIvuGqu6po58vFEo+6Nnj1NNdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=nongnu.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nkN0kETK4FYLVdivoNDUGZ0u0viRnxS05EHhYVLgfgg=; b=cal6AACjzDBFhm0famxreEXhn1Q3X1UWoIkZb83xo/9DMMmafhRmaetUn2xTpfsptkWEAWxSteGWlTwBFXEOoT+zk5nxWBl+bDnPpxKVGEM6l9tQpGXjJpVS/ph42F7twesr//s+U96yWn9ht6TdvH1/XaTxmmmescgFSJFe0QI= Received: from MN2PR20CA0007.namprd20.prod.outlook.com (2603:10b6:208:e8::20) by PH7PR12MB6812.namprd12.prod.outlook.com (2603:10b6:510:1b6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.14; Mon, 20 Jan 2025 21:31:34 +0000 Received: from BN1PEPF0000467F.namprd03.prod.outlook.com (2603:10b6:208:e8:cafe::ba) by MN2PR20CA0007.outlook.office365.com (2603:10b6:208:e8::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8335.17 via Frontend Transport; Mon, 20 Jan 2025 21:31:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by BN1PEPF0000467F.mail.protection.outlook.com (10.167.243.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8377.8 via Frontend Transport; Mon, 20 Jan 2025 21:31:34 +0000 Received: from ruby-9130host.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 20 Jan 2025 15:31:33 -0600 From: Melody Wang To: CC: Tom Lendacky , Paolo Bonzini , , , , , , , Melody Wang Subject: [RFC PATCH v2 0/3] SEV-SNP: Add support for SNP certificate fetching Date: Mon, 20 Jan 2025 21:31:13 +0000 Message-ID: <20250120213116.521519-1-huibo.wang@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0000467F:EE_|PH7PR12MB6812:EE_ X-MS-Office365-Filtering-Correlation-Id: ce745378-d46c-432c-05a1-08dd3999d05a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|82310400026|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?q?brapaISD8JQ2c3BO9+rBQm9BfnlC0Vt?= =?utf-8?q?KYzuf9LsuU8mYWdqZmaxDcMArxDxJiyHRs7/CSXGxO5JkQxxJ1C9LEgFxJWmaLo7s?= =?utf-8?q?ts264fTQ1ZSSXJSWVBYbP9AVbmtiSmsF7ysXLWR5VLDmA+fUiM2SX9u+nYJnyLbQm?= =?utf-8?q?NZKEtdahWoJmB5fYV2eQ12xytPdAOPVznnrAXtMhU+Nju4bTxivEyqb2wWTBRy4C1?= =?utf-8?q?GKh609lX7jWG/aGYzz7tlPkfgrLYvbi0QmUQVMeMnw9gRTCvQX137tuvWpOJi8bEN?= =?utf-8?q?eD8ayfmiShWgYruvHrgRL+UCU5DVOGvyZqBHRjfwhRm/2rFX3iz+UG+979BkB22yi?= =?utf-8?q?7SPg+QTB4yOWQ7bMuLIHQgJ+jcAd8yH1imXUrMxnLbcNYG3ZPDwZ06RLRMv811eTc?= =?utf-8?q?XuEAWde9vwC1gzCgsEcgtuNhOR6O5ebaC1hn+NvoByaX7WBMq37JVxrzwkMzuGmbA?= =?utf-8?q?guYXAIgj9OPwLqewp7aiAiaTBlBkDBFXo5x82cYRe3TrytsLx38rxKsmtnNHC6inX?= =?utf-8?q?CsxD40LmlMry1Q62iZWDxAa2Qpp/i5YNxdZ/t62IiqfzRH3OT7M0ZaS6A7qifH6Kl?= =?utf-8?q?mDCFH6crtTBavzs3b54mIDdKNk923AOi+Vv1LxPhbA8E4TooDtWuqhshKVktiBvWX?= =?utf-8?q?olLW3DuuwtSM+ChMlTG3Zt7EzfGDsTCOZU0gtU3vpk8uEIcQdrhb2P7Kt6ujED8W0?= =?utf-8?q?yhqwBPrnFGKQmzXuxHBCU5+hyEueS62k+WSjgMm5ULxGCmCkfTDz9cwsla3EXx+Lr?= =?utf-8?q?c/v2hD6HBNT6Y9tXqfn7BQzQgKVR0dsG3PRwHrIqmUWrkvtlRLVa802YuXsZg3+s0?= =?utf-8?q?3D1cg2gaNoahlJxh4K95PumOOYbiEUqhoMCuHYg7AXU/DUy6z2kbV3TesSvIQfBv0?= =?utf-8?q?kiIDnBrWwMVzAe7F+Rk4GImcgG/bNIQyuOJ7bR1NgPHwUS1hbT2n/2Hr9m7z60IS3?= =?utf-8?q?pQuSNY0IjbtD9jrmNQj1UuDnXiT3qf69JWAzf+3xbk6zHhfivEPr9jF3sM7kEaiii?= =?utf-8?q?PDl0icMlfKUT3+SJ8FqE3lJuttSIsTRQdnrA+hfwYeHAybLU65MM8cBUDLYe15BaN?= =?utf-8?q?zaQXpf44VH2R9FIWQlletmgnfilOF+FGN5eUujPJ0FffORLjE8dng6rcM67vd97V5?= =?utf-8?q?b0j4fl1fNFOi/BYO3iANQ9EEYlgVMgHdxZu3XrESPCN8630ibkHxwjF4M49ARgHkZ?= =?utf-8?q?5vlSqYZ2BovMvIl17lgh9z3sCM24T0Ysf+jr3euScuwx/iTQ1rvEPFr5isPNH2BUL?= =?utf-8?q?G040493bkAweM0RulZxx9CHvhmeqhvdZke8hhqHJYJlNwW/3GWkTR6BYiMKSmIoD+?= =?utf-8?q?o7B7WejFoz7PLqRE5lvn32g1O+vNT7dJES2JleavT0RUQSWf8vc6j4FMCGMu+JzHM?= =?utf-8?q?pZUzLfrjmHp?= X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2025 21:31:34.4037 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ce745378-d46c-432c-05a1-08dd3999d05a X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0000467F.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6812 Received-SPF: permerror client-ip=40.107.94.49; envelope-from=Huibo.Wang@amd.com; helo=NAM10-MW2-obe.outbound.protection.outlook.com X-Spam_score_int: -50 X-Spam_score: -5.1 X-Spam_bar: ----- X-Spam_report: (-5.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-3, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.036, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 20 Jan 2025 16:59:27 -0500 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org This patchset is also available at: https://github.com/amdese/qemu/commits/snp-certs-rfc2 and is based on top of qemu master (7433709a1477) Overview -------- The GHCB 2.0 specification defines 2 GHCB request types to allow SNP guests to send encrypted messages/requests to firmware: SNP Guest Requests and SNP Extended Guest Requests. These encrypted messages are used for things like servicing attestation requests issued by the guest. Implementing support for these is required to be fully GHCB-compliant. For the most part, KVM only needs to handle forwarding these requests to firmware (to be issued via the SNP_GUEST_REQUEST firmware command defined in the SEV-SNP Firmware ABI), and then forwarding the encrypted response to the guest. However, in the case of SNP Extended Guest Requests, the host is also able to provide the certificate data corresponding to the endorsement key used by firmware to sign attestation report requests. This certificate data is provided by userspace because: 1) It allows for different keys/key types to be used for each particular guest with requiring any sort of KVM API to configure the certificate table in advance on a per-guest basis. 2) It provides additional flexibility with how attestation requests might be handled during live migration where the certificate data for source/dest might be different. 3) It allows all synchronization between certificates and firmware/signing key updates to be handled purely by userspace rather than requiring some in-kernel mechanism to facilitate it. [1] To support fetching certificate data from userspace, a new KVM KVM_EXIT_SNP_REQ_CERTS exit type is used to fetch the data similarly to KVM_EXIT_MMIO/etc, with an associate KVM capability to detect/enable the exits depending on whether userspace has been configured to provide certificate data. Add support for this exit in QEMU. Additionally, because some of the locking behavior relies on kvm_immediate_exit, add an some infrastructure to allow for callbacks to be registered and executed upon a kvm_immediate_exit-induced exit from KVM. See the Documentation in the related KVM patches for more details on the expected usage and kvm_immediate_exit handling: https://lore.kernel.org/kvm/20241218152226.1113411-1-michael.roth@amd.com/#t [1] https://lore.kernel.org/kvm/ZS614OSoritrE1d2@google.com/ Testing ------- For testing this, use the following host kernel: https://github.com/amdese/linux/commits/snp-certs-v3 For the guest, any 5.19 or newer kernel will do. A basic command-line invocation for an SNP guest with certificate data supplied would be: qemu-system-x86_64 -smp 32,maxcpus=255 -cpu EPYC-Milan-v2 -machine q35,confidential-guest-support=sev0,memory-backend=ram1 -object memory-backend-memfd,id=ram1,size=4G,share=true,reserve=false -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,id-auth=,certs-path=/home/mroth/cert.blob -bios OVMF.fd Something like the following simple example can be used to simulate an exclusive lock being held on the certificate by management tools performing an update: #include #include #define __USE_GNU #include #include #include #include #include #include int main(int argc, void **argv) { int ret, fd, i = 0; char *path = argv[1]; struct flock fl = { .l_whence = SEEK_SET, .l_start = 0, .l_len = 0, .l_type = F_WRLCK }; fd = open(path, O_RDWR); ret = fcntl(fd, F_OFD_SETLK, &fl); if (ret) { printf("error locking file, ret %d errno %d\n", ret, errno); return ret; } while (true) { i++; printf("now holding lock (%d seconds elapsed)...\n", i); usleep(1000 * 1000); } return 0; } For requesting attestation with certificate data attached, you can use something like the following tool/workflow: https://github.com/virtee/snpguest?tab=readme-ov-file#extended-attestation-workflow The format of the certificate blob is defined in the GHCB 2.0 specification, but if it's not being parsed on the guest-side then random data will suffice for testing the KVM bits. Any feedback/review is appreciated. Thanks! -Melody Changes from v1 to v2: - Recreation race problem: Add a while(1) loop using the libvirt example with fstat and stat for the locking certificate blob code in open_certs_locked() to fix the recreation race problem suggested by Daniel P. Berrangé. - Fix the json format and filename suggested by Markus Armbruster. - Some text formulation comments. Michael Roth (3): linux-headers: Update for 6.12 and SNP certificate support accel/kvm: Add kvm_immediate_exit callback infrastructure i386/sev: Add KVM_EXIT_SNP_REQ_CERTS support for certificate-fetching accel/kvm/kvm-all.c | 43 ++++++ include/system/kvm.h | 3 + linux-headers/linux/kvm.h | 10 ++ qapi/qom.json | 21 ++- target/i386/kvm/kvm.c | 10 ++ target/i386/sev-system-stub.c | 5 + target/i386/sev.c | 277 ++++++++++++++++++++++++++++++++++ target/i386/sev.h | 2 +- 8 files changed, 369 insertions(+), 2 deletions(-)