Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Mon, 4 Dec 2023 16:30:02 -0800
From:   Dan Williams <dan.j.williams@intel.com>
To:     Dionna Amalie Glaze <dionnaglaze@google.com>,
        Sean Christopherson <seanjc@google.com>
CC:     Michael Roth <michael.roth@amd.com>,
        Alexey Kardashevskiy <aik@amd.com>, <kvm@vger.kernel.org>,
        <linux-coco@lists.linux.dev>, <linux-mm@kvack.org>,
        <linux-crypto@vger.kernel.org>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>, <tglx@linutronix.de>,
        <mingo@redhat.com>, <jroedel@suse.de>, <thomas.lendacky@amd.com>,
        <hpa@zytor.com>, <ardb@kernel.org>, <pbonzini@redhat.com>,
        <vkuznets@redhat.com>, <jmattson@google.com>, <luto@kernel.org>,
        <dave.hansen@linux.intel.com>, <slp@redhat.com>,
        <pgonda@google.com>, <peterz@infradead.org>,
        <srinivas.pandruvada@linux.intel.com>, <rientjes@google.com>,
        <dovmurik@linux.ibm.com>, <tobin@ibm.com>, <bp@alien8.de>,
        <vbabka@suse.cz>, <kirill@shutemov.name>, <ak@linux.intel.com>,
        <tony.luck@intel.com>,
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        <alpergun@google.com>, <jarkko@kernel.org>, <ashish.kalra@amd.com>,
        <nikunj.dadhania@amd.com>, <pankaj.gupta@amd.com>,
        <liam.merwick@oracle.com>, <zhi.a.wang@intel.com>,
        Brijesh Singh <brijesh.singh@amd.com>,
        Dan Williams <dan.j.williams@intel.com>,
        <dan.middleton@intel.com>
Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for
 SNP_GUEST_REQUEST NAE event
Message-ID: <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch>
References: <20231016132819.1002933-1-michael.roth@amd.com>
 <20231016132819.1002933-49-michael.roth@amd.com>
 <CAAH4kHb=hNH88poYw-fj+ewYgt8F-hseZcRuLDdvbgpSQ5FDZQ@mail.gmail.com>
 <ZS614OSoritrE1d2@google.com>
 <b9da2fed-b527-4242-a588-7fc3ee6c9070@amd.com>
 <ZS_iS4UOgBbssp7Z@google.com>
 <20231110220756.7hhiy36jc6jiu7nm@amd.com>
 <ZU6zGgvfhga0Oiob@google.com>
 <CAAH4kHYPAiS+_KKhb1=8q=OkS+XBsES8J3K_acJ_5YcNZPi=kA@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAH4kHYPAiS+_KKhb1=8q=OkS+XBsES8J3K_acJ_5YcNZPi=kA@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uRG7dOVFQRCLnoT4Fh/KQZnKz9yhNAOsurx3nDqSgvMwYk27aU0zwjZrRH+F?=
 =?us-ascii?Q?qiKOPpqM9g+YVWtquMdLOE500jivC3AoUtrGKVUNIk+sq2pzNWzweeEaTqKm?=
 =?us-ascii?Q?hEaudyafq9nBDUOEnIVvD728Ejnoq7Wuj1jlFJ56yt7RG3pmGMas6IcXpSIa?=
 =?us-ascii?Q?uM8KIIWN7LIk+bL1LmsWkSxLqQnSvgPaXByWyGX2UfqF2YhhnGZuG37zeVDY?=
 =?us-ascii?Q?HPt0d6j0DgkHHxF6prY4yqINj4J3SmsbwdNNczTcYsF0on50PR2Enmdl/ijG?=
 =?us-ascii?Q?Y0a5akBe9uNGgnISYUpMIHwZCaHPUPkofk0FPoKLAUO0+VgCytWt/mRGzNh0?=
 =?us-ascii?Q?/TWWP04RcgivWd+h/USNdYixn6+1Vj7kR4GYn3mAav47NLz7/ZjRpzVRGzYm?=
 =?us-ascii?Q?kGTQMJJCj64pYhkX1V5eHRoerwc8lc2biSM6hSTcWNmRo44wgTENJM5At4A0?=
 =?us-ascii?Q?mIl4uHgEhzyKIiccWOiqkDrmeIf9tDFvMnhyARIk8Qm06dRN58Ne0ymYT4Pa?=
 =?us-ascii?Q?gqOVYG/RWvT9+UauGkARNtkC2TnGCJ3BT9mab1Uu4lhMULZ5L9JzCcMcdro8?=
 =?us-ascii?Q?aFHisW4u691BeDGxZsmvRwyql0f7TBE3yLG+UP0w4TMsTGq0hsi/2V7mGSee?=
 =?us-ascii?Q?vwlYEuSQmcYgSHMzQgPsih05I8JhYOWHqUxSmlrSaBkq4Di0voF4IdDkYuFK?=
 =?us-ascii?Q?nB2Oc53MecDWOQG5aoF/xJy9J7G9wdvhuvGGinJ6iVXE0JvZha0+P/MoA8kS?=
 =?us-ascii?Q?kuGhmoFuKlH4hyiqc2fWnC+2IejqxTCDkbjRFSdcCE8Tn3P9Z0L1nNJZBHJ3?=
 =?us-ascii?Q?uOqi9+FSetjyKHJEZ1lQD7v6/eOU7PsAOhop7yxmq+2da49g7SRWukA7RdhU?=
 =?us-ascii?Q?Iu9qsDYFm6LinVEZX/8u0AX8EjEulz/50rlMbjFdMmnBcse0HFVxjccRxLu9?=
 =?us-ascii?Q?tw+eXB/P3KPMXRxRolS+u0C/jZY4E6U4JqCYEzRak5XLdCxF9GnE4zIyM5sx?=
 =?us-ascii?Q?RL7sq/CusSd8dD0eZEj++fuTUYTLkLmH5DjmfeT0Q0oQ4lXyU1LymVfW4jcd?=
 =?us-ascii?Q?YVchRvTItOZ+kLLovwNfoAkyyb98S5lnxoN0XcTTpJHK0NhP/XgapycZ1mix?=
 =?us-ascii?Q?a7B6wKjTi5YOKju9SmgvXkKoioYNUie6R/uR5tPDKrpdN32/jkj7fxWLgk8c?=
 =?us-ascii?Q?FgXP1qQgAZ1phD2XdquAYcSwKf4BRg1ALjSfdQnLvfgphnt1SVVyIim7z/xf?=
 =?us-ascii?Q?Mg7Oz0Xbb0Pr9IEh2mqq2/VLBQoqcBL7KGQTSMF0Zt/xNcXEgmNxXg3qoosw?=
 =?us-ascii?Q?ENn7uVcxdb1bRslW19ppX/9xM8bwWcnlKXTxRMdOuv3MLx/+w7h272HG6E42?=
 =?us-ascii?Q?7OqAx0VuFPDoScsXg8PmzLwrZowOCNIh0/qjsIQDuyhCtGmyXbIZ/8WG7cPo?=
 =?us-ascii?Q?sGI2jm0HfNTcHP1obpTG3HZzFIaSugMfGJpaFvSkOJFzByLIDxwhZFN37bfG?=
 =?us-ascii?Q?qlQN3QnCekO/E9g+GwWPP2YuJGM+/mHIZb0PwlcosNuFv94Cg7JzdmLBpOJy?=
 =?us-ascii?Q?RDgnm5clsQjJARWAisAAXM2SuQPGUagF0rx4NGCb5eMbR2H62TtZJZT3l9wc?=
 =?us-ascii?Q?wA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dd64637d-5662-493a-9b85-08dbf529552d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2023 00:30:08.0675
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WxOBSmNm5OfSCiz272W9kkmQoKF++l7Mzd4plTCap/ZZGhcyYL1j5Qhq9/MR2fc2/nW3K3vxC4BKPrDjHRQt9EB/VA3N+jA8GnVDwRwIQI8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7502
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 04 Dec 2023 16:30:30 -0800 (PST)

[ add Dan Middleton for his awareness ]

Dionna Amalie Glaze wrote:
> > > So we're sort of complicating the more common case to support a more niche
> > > one (as far as userspace is concerned anyway; as far as kernel goes, your
> > > approach is certainly simplest :)).
> > >
> > > Instead, maybe a compromise is warranted so the requirements on userspace
> > > side are less complicated for a more basic deployment:
> > >
> > >   1) If /dev/sev is used to set a global certificate, then that will be
> > >      used unconditionally by KVM, protected by simple dumb mutex during
> > >      usage/update.
> > >   2) If /dev/sev is not used to set the global certificate is the value
> > >      is NULL, we assume userspace wants full responsibility for managing
> > >      certificates and exit to userspace to request the certs in the manner
> > >      you suggested.
> > >
> > > Sean, Dionna, would this cover your concerns and address the certificate
> > > update use-case?
> >
> > Honestly, no.  I see zero reason for the kernel to be involved.  IIUC, there's no
> > privileged operations that require kernel intervention, which means that shoving
> > a global cert into /dev/sev is using the CCP driver as middleman.  Just use a
> > userspace daemon.  I have a very hard time believing that passing around large-ish
> > blobs of data in userspace isn't already a solved problem.
> 
> ping sathyanarayanan.kuppuswamy@linux.intel.com and +Dan Williams

Apologies Dionna, I missed this earlier. 

> 
> I think for a uniform experience for all coco technologies, we need
> someone from Intel to weigh in on supporting auxblob through a similar
> vmexit. Whereas the quoting enclave gets its PCK cert installed by the
> host, something like the firmware's SBOM [1] could be delivered in
> auxblob. The proposal to embed the compressed SBOM binary in a coff
> section of the UEFI doesn't get it communicated to user space, so this
> is a good place to get that info about the expected TDMR in. The SBOM
> proposal itself would need additional modeling in the coRIM profile to
> have extra coco-specific measurements or we need to find some other
> method of getting this info bundled with the attestation report.

SBOM looks different than the SEV use case of @auxblob to convey a
certificate chain.

Are you asking for @auxblob to be SBOM on TDX and a certchain on SEV, or
unifying the @auxblob format on SBOM?

> My own plan for SEV-SNP was to have a bespoke signed measurement of
> the UEFI in the GUID table, but that doesn't extend to TDX. If we're
> looking more at an industry alignment on coRIM for SBOM formats (yes
> please), then it'd be great to start getting that kind of info plumbed
> to the user in a uniform way that doesn't have to rely on servers
> providing the endorsements.
> 
> [1] https://uefi.org/blog/firmware-sbom-proposal

Honestly my first reaction for this ABI would be for a new file under
/sys/firmware/efi/efivars or similar.