Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Tue, 5 Dec 2023 15:11:30 -0800
From:   Dan Williams <dan.j.williams@intel.com>
To:     Dionna Amalie Glaze <dionnaglaze@google.com>,
        Dan Williams <dan.j.williams@intel.com>
CC:     Sean Christopherson <seanjc@google.com>,
        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.middleton@intel.com>
Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for
 SNP_GUEST_REQUEST NAE event
Message-ID: <656fae221bf90_45e01294d2@dwillia2-xfh.jf.intel.com.notmuch>
References: <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>
 <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch>
 <CAAH4kHb7cfMetpC=AYy=FjTTve6g0W8NZdeSwQ8uVxkqi2491Q@mail.gmail.com>
 <656f82b4b1972_45e012944e@dwillia2-xfh.jf.intel.com.notmuch>
 <CAAH4kHb9O9FeaTmNuNAkhrdrDLJPo8qgD5vNow3w-sY-DA4Ung@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAH4kHb9O9FeaTmNuNAkhrdrDLJPo8qgD5vNow3w-sY-DA4Ung@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YTdNNU1Ea3VuYk1JK1VuWnB2b2tNd1ViZFA3cjhLSXRsdHVNM2F6YkFtcDBq?=
 =?utf-8?B?YU8xb1pDWTI2QjY1T05yeFdRUlQveFAvMCtvRi9QYTdwNWhBdXJFSUFKdFcw?=
 =?utf-8?B?VFZWUWR2ZHVyRms2TWV0REd3ZkhEeXJGaHZ4ckVJQ0Y5ekg2UC9OVkFrd0Zw?=
 =?utf-8?B?YVZMNnQ2RnRSYWR0S3M1ZVJiOHYrL2lBZVAraVFURk4zei9raW9KSm8wWS9V?=
 =?utf-8?B?VjlxMkRJRHZBWEV4M0JlWHd0eVJJanh3Q2M4eHdSTWFUY010SHBNOUlaQTk4?=
 =?utf-8?B?cEtISTNEWnZ3ZStEUFpIYlk2NDhFVm1NTlRzSUdNNGFWK0Zlalh4VURFZmcy?=
 =?utf-8?B?eFF0WlpuL3pxMzJHeTZhdVZsbXRRSEZETGFQSkFpV0NjMW1PTmcvc3MwOEFF?=
 =?utf-8?B?VWV6dG1Ca0ZFZERjR3JUVXZZZndpM0dJTGhBQnRaNDh6Q1h6V3JWZ1Z4ZVB5?=
 =?utf-8?B?MFlqdmtzUGF2VEM4Q01SVi9SaWZialZKbzRwS2YwTnhRcWx0SWFBK3N0aWl0?=
 =?utf-8?B?MW45UXY0SU01UE54S3BYeEt2VTEzUGRNVzRvdWxSN2psUk51V1JQZTFmZGkz?=
 =?utf-8?B?amJ3VjhNNDdKRFYzaG5JT1lUdnBESmxpREpYMEk3M2xzWlhIM09qaVJWS1cr?=
 =?utf-8?B?S3NIdUk5d3RPdzhEczZVb0lLN3ovZUVLZlNPQW5LdzRwVS9jc0t3NkVSZ0Uw?=
 =?utf-8?B?b0pxbzk5bDZuT3BMTDcwZnNWTXhqVVVxYkZ4b1k1MlJJZlhqYS9OVmNTbzRF?=
 =?utf-8?B?aTBDS1BjZlUxajd1N3NKZHIyVGxhdnoyM3NDYnhIMUVlSEk3VDlqS2R6dFRv?=
 =?utf-8?B?RmtUWFN4ZHRqRmxkT2s4MzFONGRUMXBqd2YvRnZ1bHJmOE1qK3Y1bXU3UjVB?=
 =?utf-8?B?K3NXc2ZOcndScUxuMXVlSGJaVWtYTFdEOHV5ZXFlaC9iSDN2UG0wNzM3MHky?=
 =?utf-8?B?R0Z6VDR1Y0I4YmVaazNEaExvME5nenEvQUNJeDRNSUp4NU1mcENiOUJBc3Uy?=
 =?utf-8?B?aWpvVzBqTVlDMVlWUnFOY200WG8vdmpzSzhzejEzVmVVRU5ScFE2WFhERnJ0?=
 =?utf-8?B?bS9VQWNseEppQUdSNlFpVUQ2V2M2cUxjZExGb05PdzM0eWNRRlBvRlVvTHdh?=
 =?utf-8?B?c05zMUt3TEpZRVMrZlBXZWRrd29Ra3A2U010ZlZ5MldxUkpVczVQU2hxUWlD?=
 =?utf-8?B?eHBEZzczZUlFaS8xQXNPVlAyWk15dGxlWHo4RjhxcGZDTUl4MXVIYzhuNnJG?=
 =?utf-8?B?cXZvejNXRG44cDFLWGdGektZS0MvNXdwWkNoRUk5QzFCWGJlcDNSNGU0NEkr?=
 =?utf-8?B?NzVRMWdna2E2eUdkVnhPZkVaS2NJQmh2cWhsTm5hbzY4QlZ4bzZ4YjVBZE9t?=
 =?utf-8?B?N2dEY2xoTC9ob0pseWpRbm1nRVNKMytLMzlhOXppMWQ3eGVlZUZYa1VZWmdM?=
 =?utf-8?B?cXBiRUVUWmdvMEV0ditjRmcxYmJORTFjbWhvRnk5cDVhaUJFQlhtd2Y0Sllt?=
 =?utf-8?B?Vm5xdmtWMnpINnZiTWdIVjJXZkR6d2FkNCtFTm56ajVSc1NsSkxnaFVUaGFQ?=
 =?utf-8?B?SjFLMVlnMStCNThEaExxM1VwelAvSXBtMlB1dng3Qk5ZVG9OdXIrWU5rS3d5?=
 =?utf-8?B?MXJkb3AxaENTK0I5L3NrSEM1ZHdsRk5BekI5T3YrdWxRcThpNENGc3RpN2Iw?=
 =?utf-8?B?STkwRVpDL0RjM0pYV3VrZFMzTTdXVlEwaVJNeEJNNFZXclhtRlVtTGZBWGpN?=
 =?utf-8?B?WVNkSGVJV2tqRFQ0Q2xXRFdaUStzQW9Ka0pRTG5PUC8wc241Vm5Dek9NcW5q?=
 =?utf-8?B?VGVjUFFFbzNWcWw5VzJ1U01PV0o5L1lJNjdIeEdLZUNDRlJ5N0pLUFJZWDA4?=
 =?utf-8?B?R3Q0ZUE1aWt1R05BcnBWMy9tK1ExNHVHMm4wWlZUcm0yS0N4elZxV3RBV045?=
 =?utf-8?B?OC9nSnBMMmxER2V5bUlNazBZSE5ML3NHeGw2SDNFS1dteFpWVHRCY2RtT0Ew?=
 =?utf-8?B?RHNlbEFCNjdqYktwKzhOcFhxbjdyVVVNMDJwNlBNeHNzS01uMkF3Q2s3SGhq?=
 =?utf-8?B?REhCdmFXMzNrTGNjeUNzN08wZDNPeGM4TCtHMzBPTFU0UUorSzUzZ1c4Ynpu?=
 =?utf-8?B?V29GV1dyeEVaOW4wVE5Sck1Bb2MySTZaa2g3SzBiamw5MzA2SzVNWFk4Z0No?=
 =?utf-8?B?d2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1132f261-ff9a-4ae0-99af-08dbf5e786cd
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2023 23:11:35.3690
 (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: ZvCJnY0XNFt17GRw7ikruh+CkOtYrgImIibjRX6E59c0D2S7khlKhYSaf1MYmnsE9wrUJRE4+0yOwulfdeKqiWg7cQc0dTk/VqG/7pPtJIc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB7142
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 howler.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 (howler.vger.email [0.0.0.0]); Tue, 05 Dec 2023 15:11:56 -0800 (PST)

Dionna Amalie Glaze wrote:
> On Tue, Dec 5, 2023 at 12:06 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > [ add Ard for the SBOM sysfs ABI commentary ]
> >
> > Dionna Amalie Glaze wrote:
> > [..]
> > > > > 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.
> > >
> > > For UEFI specifically that could make sense, yes. Not everyone has
> > > been mounting efivars, so it's been a bit of an uphill battle for that
> > > one.
> >
> > I wonder what the concern is with mounting efivarfs vs configfs? In any
> > event this seems distinct enough to be its own /sys/firmware/efi/sbom
> > file. I would defer to Ard, but I think SBOM is a generally useful
> > concept that would be out of place as a blob returned from configfs-tsm.
> >
> > > Still there's the matter of cached TDI RIMs. NVIDIA would have
> >
> > I am not immediatly sure what a "TDI RIM" is?
> >
> 
> I might just be making up terms. Any trusted hardware device that has
> its own attestation will (hopefully) have signed reference
> measurements, or a Reference Integrity Manifest as TCG calls them.

Ah, ok.

> 
> > > everyone send attestation requests to their servers every quote
> > > request in the NRAS architecture, but we're looking at other ways to
> >
> > "NRAS" does not parse for me either.
> >
> 
> That would be this https://docs.attestation.nvidia.com/api-docs/nras.html

Thanks!

> > > provide reliable attestation without a third party service, albeit
> > > with slightly different security properties.
> >
> > Setting the above confusion aside, I would just say that in general yes,
> > the kernel needs to understand its role in an end-to-end attestation
> > architecture that is not beholden to a single vendor, but also allows
> > the kernel to enforce ABI stability / mitigate regressions based on
> > binary format changes.
> >
> 
> I'm mainly holding on to hope that I don't have to introduce a new
> runtime dependency on a service that gives a source of truth about the
> software that's running in the VM.
> If we can have a GUID table with a flexible size that the host can
> request of the guest, then we can version ABI changes with new GUID
> entries.
> It's a big enough value space without vanity naming opportunities that
> we can pretty easily make changes without incurring any guest kernel
> changes.

So it's not only SBOM that you are concerned about, but instead want to
have a one stop shop for auxiliary evidence and get the vendors agree on
following the same GUID+blob precedent that is already there for the AMD
cert chain? That sounds reasonable, but I still feel it should be
limited to things that do not fit into an existing ABI namespace.

...unless its evidence / material that only a TVM would ever need.