From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAE457A for ; Mon, 8 Aug 2022 19:27:54 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-328a1cff250so91318447b3.6 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=lhfHld9zxt/HJPTWdeuMn7hvsdJdGNNXVE+fuCAAi6VYfqWdiKhBj6/nGbUTDoDSv4 FjMHkJdBfWkSh2bAJeKNaKX/Tow2dgLBxXeAwfl91b/oT0h9YJvR2JioZueudBpeG1b7 EzINzSdLUwKN8jYTo6/BeBL80HkF937Iu5Apx6ENJF92laNa1GriYkhKrzK3C+MY8x2v 7mYtPl4bNHq+Gh8ARDTDROuXIal9W3HIgaxKilEczKMkThqyNcKBvfPdQ+cZNSvJC+6O 1m1+BppS1yiclprJoBncSUserb8gBcheV/W5gCI9w0TlUGAoedse+CIYJ1hCKnTxXzqH rnfw== X-Gm-Message-State: ACgBeo33CxyRECnyL7vTZ02S2SuBpU4QQ5kkBovxeGU1oRV3gtB+o+Cm 3+oqQJm17tF9NjDvBqC4NF0WZT09RqpQqE590RyU2Q== 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) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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" 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)