[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CUE26Z3BST2Z.3OTO2IP6Y5PFV@seitikki>
Date: Fri, 28 Jul 2023 19:40:27 +0000
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Dan Williams" <dan.j.williams@...el.com>, <dhowells@...hat.com>
Cc: "Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Dionna Amalie Glaze" <dionnaglaze@...gle.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Samuel Ortiz" <sameo@...osinc.com>, <peterz@...radead.org>,
<linux-coco@...ts.linux.dev>, <keyrings@...r.kernel.org>,
<x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] keys: Introduce tsm keys
On Fri Jul 28, 2023 at 7:30 PM UTC, Dan Williams wrote:
> One of the common operations of a TSM (Trusted Security Module) is to
> provide a way for a TVM (confidential computing guest execution
> environment) to take a measurement of its run state and use that with a
> key-exchange protocol to establish a shared secret with a third-party /
> remote attestation agent. The concept is common across TSMs, but the
This is obfuscated "white paper" alike language.
I have no idea what TSM's and TVM's are and I do not want to know. Even
confidential computing is useless buzzword in the context of providing
a key type for attestation.
I would replace "tsm" with "attestation".
BR, Jarkko
Powered by blists - more mailing lists