From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDAF1C00140 for ; Mon, 8 Aug 2022 19:27:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 174356B0071; Mon, 8 Aug 2022 15:27:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 122C98E0001; Mon, 8 Aug 2022 15:27:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F05306B0074; Mon, 8 Aug 2022 15:27:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DF3376B0071 for ; Mon, 8 Aug 2022 15:27:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B0BF1140CDC for ; Mon, 8 Aug 2022 19:27:54 +0000 (UTC) X-FDA: 79777410468.24.BECCEAB Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 5A8C318014F for ; Mon, 8 Aug 2022 19:27:54 +0000 (UTC) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-31f443e276fso91610167b3.1 for ; Mon, 08 Aug 2022 12:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=KBxnTL7K25Hs8Wv1cjszwJQN73tLNnDr4U0ROfrziZM=; b=bmhDQvAoVXlswYykpII5N+dpGoKRhyIPQd6917OIYRgTBKCDiocZ8hBciok/W8LUze EIjX5hN3yiimne61Nb3aTNlb9nBZQmslL5TCM0d1LA7i2zQ/H/4aTTagUPnTlBHd7NNH jp49XCAYeppQJH6DZPAkhkhwaPCdGbr5LzxpBy1SPKkfFCpwOrhcOT7IXsuqUQ7ZkHXk 2EN9b/GFRVyKWz6SZA4dRgUqR4NSQvsXiltm/yl8BfV5WDZTRhGGdA6KVukBUihgBOyH 55C0EgVneBrxf/TZZbWXKThHVk8W/icGPUW+SM47rOw7socQV2WRJvnbyYLErUkfE5Gt l21w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=KBxnTL7K25Hs8Wv1cjszwJQN73tLNnDr4U0ROfrziZM=; b=YteyxpeqFi1c30686pl9o6EuSy72zSJHmbPwNy12KU+FQyYO7YPjTOveeOqEFdeuGQ QbfaafM5fdNBI9Vi+cwZK34fbZQqwVSYFjh66LRDG75XGevOXWIDAK/SnNLYitI+nxqH l+nuAhi0I08sj1yKD2o0BqYnyfoSindyRXxzPjD2gdTe/ERVMM85ie8sMDmyU/JCd5il L3NH8tGOSPwcEtAZ23XmjrulOgqxO9/0xY2LkTMWcYoEcQVgf1vSUGCY0JEWe+LatijD RQuW2oG/90cJgve8Y/zp8cBBbHozweJ7IKyV+YRf116NoxCGy5W18L4u/tt2xIP4OfzU gPSg== X-Gm-Message-State: ACgBeo0zTY42XyapoJsLQlsq1MdDwoTQZpwm1He5UGCVPz8IZN6emQB1 4iXTAH6453DR5iTIS+CcAvmSwkvyYmyzZH8DQfAdyA== X-Google-Smtp-Source: AA6agR4CqP2bI2zng0Vr3lzhitvUH2Let9QUGzmufNUJrDlFIezoBA22p9QF8TCyK0rnYyUKBgURyaJWteXCXsvKjg8= X-Received: by 2002:a0d:da41:0:b0:329:91e7:fd06 with SMTP id c62-20020a0dda41000000b0032991e7fd06mr10086726ywe.436.1659986873539; Mon, 08 Aug 2022 12:27:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dionna Amalie Glaze Date: Mon, 8 Aug 2022 12:27:42 -0700 Message-ID: Subject: Re: [PATCH Part2 v6 17/49] crypto: ccp: Add the SNP_{SET,GET}_EXT_CONFIG command To: Jarkko Sakkinen Cc: Ashish Kalra , "the arch/x86 maintainers" , LKML , "open list:X86 KVM CPUs" , linux-coco@lists.linux.dev, Linux Memory Management List , linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , hpa@zytor.com, Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , vkuznets@redhat.com, Jim Mattson , Andy Lutomirski , dave.hansen@linux.intel.com, slp@redhat.com, Peter Gonda , Peter Zijlstra , srinivas.pandruvada@linux.intel.com, David Rientjes , dovmurik@linux.ibm.com, tobin@ibm.com, Borislav Petkov , "Roth, Michael" , Vlastimil Babka , "Kirill A. Shutemov" , Andi Kleen , tony.luck@intel.com, Marc Orr , Kuppuswamy Sathyanarayanan , Alper Gun , dgilbert@redhat.com Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659986874; a=rsa-sha256; cv=none; b=qoe8HlN5C5VHRLdRnVhfVRq0f9oz6qnY+4KTJzMhi3z1gMbiHSyxcydFOIc3BGq0cn5BG6 XeoHnkesBQXhp2GiMT6s3RyqkCJsvovnHsJvbdgeiezCi1kQkrtnXTRnHk+B9lB3xF/+VZ HmZOVLBR5tb+P9bnHdIvcWTzg9AzIVw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659986874; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KBxnTL7K25Hs8Wv1cjszwJQN73tLNnDr4U0ROfrziZM=; b=fUYEWFuKrQETD373FvU3/tV/v8BBTPY/W5nGRefWWWBz+9HqVHHB1dwReniYMkiU9DWJy2 rHNDpqs2+Hr7n6SEJroGd+QN0IMFO53ZG57Obw7O2aQkZWJJQkwFWd6DOxOXBUL4v+9VSO C7Ye1ILA8Pp/XF8m59XM1lDviXe+FCo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bmhDQvAo; spf=pass (imf06.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: k8shaq6iys8dzymmmy4sj57qk1nee8zp X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5A8C318014F Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bmhDQvAo; spf=pass (imf06.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1659986874-570687 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: To preface, I don't want to delay this patch set, only have the conversation at the most appropriate place. > > > The SEV-SNP firmware provides the SNP_CONFIG command used to set the > > system-wide configuration value for SNP guests. The information includes > > the TCB version string to be reported in guest attestation reports. > The system-wide aspect of this makes me wonder if we can also have a VM instance-specific extension. This is important for the use case that we may see secure boot variables included in the launch measurement, making offline signing of the UEFI image impossible. We can't sign the cross-product of all UEFI builds and every user's EFI variables. We'd like to include an instance-specific certificate that specifies the platform-endorsed golden measurement of the UEFI. An alternative that doesn't require a change to the kernel is to just make this certificate fetchable from a FAMILY_ID-keyed, predetermined URL prefix + IMAGE_ID + '.crt', but this requires a download (and continuous hosting) to do something as routine as collecting an attestation report. It's up to the upstream community to determine if that is an acceptable cost to keep the complexity of a certificate table merge operation out of the kernel. The SNP API specification gives an interpretation to the data blob here as a table of GUID/offset pairs followed by data blobs that presumably are at the appropriate offsets into the data pages. The spec allows for the host to add any number of GUID/offset pairs it wants, with 3 specific GUIDs recommended for the AMD PSP certificate chain. The snp_guest_ext_guest_request function in ccp is what passes back the certificate data that was previously stored, so I'm wondering if it can take an extra (pointer,len) pair of VM instance certificate data to merge with the host certificate data before returning to the guest. The new required length is the sum total of both the header certs and instance certs. The operation to copy the data is no longer a memcpy but a header merge that tracks the offset shifts caused by a larger header and other certificates in the remaining data pages. I can propose my own patch on top of this v6 patch set that adds a KVM ioctl like KVM_{GET,SET}_INSTANCE_SNP_EXT_CONFIG and then pass along the stored certificate blob in the request call. I'd prefer to have the design agreed upon upfront though. -- -Dionna Glaze, PhD (she/her)