From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by mx.groups.io with SMTP id smtpd.web08.1751.1632385559668393760
 for <devel@edk2.groups.io>;
 Thu, 23 Sep 2021 01:25:59 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=blds3Wm5;
 spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1632385558;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=ecbYA+TnQHVMK9Jtc9DIcBxypiIxpA8ValZY2Hdkhqo=;
	b=blds3Wm5z6eK3e+Lv13o+zd3OoumVvQOmDLSIlAPWZRIqvHn0zBBTc8R58ICNBoksV3For
	4KJuwV8jQkAJlJG22xsnAZCIDHEmWrTzsvkfFmvKZv2MgDXjJm/JPjGA+UiYROXdvVvPwc
	tv7x/J7G0u7S/7CeRQkaoL+vM3OuiYo=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-286-D9TRbu9MOayWZcH9F4m6Gg-1; Thu, 23 Sep 2021 04:25:57 -0400
X-MC-Unique: D9TRbu9MOayWZcH9F4m6Gg-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8F4678030AF;
	Thu, 23 Sep 2021 08:25:55 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.193.134])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 4CC3460BF1;
	Thu, 23 Sep 2021 08:25:55 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 7F380180038E; Thu, 23 Sep 2021 10:25:53 +0200 (CEST)
Date: Thu, 23 Sep 2021 10:25:53 +0200
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Michael Roth <michael.roth@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>, devel@edk2.groups.io,
	James Bottomley <jejb@linux.ibm.com>, Min Xu <min.m.xu@intel.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Erdem Aktas <erdemaktas@google.com>
Subject: Re: [PATCH v8 08/32] OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values
Message-ID: <20210923082553.dbsovkrnnnxmkc7a@sirius.home.kraxel.org>
References: <20210920184604.31590-1-brijesh.singh@amd.com>
 <20210920184604.31590-9-brijesh.singh@amd.com>
 <20210922075558.zpbcyceegytfumqq@sirius.home.kraxel.org>
 <20210922231007.566nxiaqagtwjlps@amd.com>
MIME-Version: 1.0
In-Reply-To: <20210922231007.566nxiaqagtwjlps@amd.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

  Hi,

> One issue with that is that the contents of the CPUID page are not part
> of guest measurement that will be checked later during attestation (only
> the metadata such as page type/location is recorded in the measurement).
> 
> [ more details snipped ]

Thanks, that makes sense.

> That said, for the !SNP case, additional handling *could* be added to make
> use of the CPUID page, but in that case it wouldn't be validated by firmware,
> so isn't much better security-wise than asking KVM.

Well, the intention would be more to (a) be able to test the code
without SNP hardware (for example in public CI) and (b) avoid trapping
into kvm if we don't have to.

It is clearly not a priority though, we can look into that once all the
SNP bits are merged in edk2 and qemu.

take care,
  Gerd