Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 3 Aug 2023 19:40:02 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jarkko Sakkinen <jarkko@kernel.org>,
        Peter Gonda <pgonda@google.com>,
        "Dan Williams" <dan.j.williams@intel.com>
CC:     <dhowells@redhat.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Dionna Amalie Glaze <dionnaglaze@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Samuel Ortiz <sameo@rivosinc.com>, <peterz@infradead.org>,
        <linux-coco@lists.linux.dev>, <keyrings@vger.kernel.org>,
        <x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] keys: Introduce tsm keys
Message-ID: <64cc650233ef9_782a329489@dwillia2-xfh.jf.intel.com.notmuch>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com>
 <169057265801.180586.10867293237672839356.stgit@dwillia2-xfh.jf.intel.com>
 <CAMkAt6ot9zyUL9Ub-qYq+d9v-6rTft4ea2mUxp3o1s3GVFq7nw@mail.gmail.com>
 <CUHEL5OD3UR8.FRBWNF6MTP1Y@suppilovahvero>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CUHEL5OD3UR8.FRBWNF6MTP1Y@suppilovahvero>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?r+CzQ/2goR74j3p69c/wp63cx4/u2Uh4AxVpGeaiL4lG3PEU+nso9j55vXkH?=
 =?us-ascii?Q?8A9A3jancIMuq3FRg4Xer4m9peKWaTKP9Vkd+whpaXsj4Ime3Vl1jpVxRLAu?=
 =?us-ascii?Q?cCxowvAqu6i63xiBHplqIWc4wecy3sxYCP9zwbGcsxOeXhFN5NQPgSKzdfzJ?=
 =?us-ascii?Q?RxYZkhacfZtyE8APsc8eVgY4VTU/+09xQ6V/4vSNalSV35LApLOW4dXep9t8?=
 =?us-ascii?Q?XKwQwD2hsVs+HBa/qAUwTRZQXywH9Ep2MiQcxErTkgkV4RbwXoBXLpvczP6r?=
 =?us-ascii?Q?fa6n6mYlcuxcvtvPiNNFpgTwljmlN4SGrn4TeeHUFV5xpD8aKG+JPeUwhhvk?=
 =?us-ascii?Q?LpKkNgTfsnbjk/2iuKfzT30aMjfKI40HBm/wDmdQSVIg5vcSAZhDFsWsPMqV?=
 =?us-ascii?Q?0gqueVpc6idDvjQG8aAQ22NxGbUkVz3dP17rtDGjU6/DdsBJDPAV4Zp7a5C3?=
 =?us-ascii?Q?QyhAKd+jFSboKr1eoHPRp+TlUFhbpmqa/pFZXNcKUwqRREfwv14xF6ThXojM?=
 =?us-ascii?Q?xrq7UOX0CMTEvTUNPJql02u3yEIR/6taxkL9VXX4KwhfqEEorEMYkZDFOTue?=
 =?us-ascii?Q?cE4gDJS4B4u4j2tYrN+Owo/tUZLP3iUPoBhRKdn2sOpedybgr3y0eTZDkMOd?=
 =?us-ascii?Q?/gnRXZ7S7EOoVzmIUS1aG865++q/eK5d2kvHXhEFQOh4YfK5dT+IhqePXsrP?=
 =?us-ascii?Q?Duonq9VAZjw8qtWR0bxI6ryw0iCbexCnazc57xMRu77qqeWaOCMFDb7O9KsQ?=
 =?us-ascii?Q?YpliMLacmOKiWXl8q2Vm4lM29OGY6KCRPui3BCLgGbjqLk1FxHYsnKDpZU8u?=
 =?us-ascii?Q?Z3rVAxkbwYOe/kH6FcxiXWxdck7fdqvDc0DzFqfATJXzhMvgUnTzzD6arO4L?=
 =?us-ascii?Q?1j5dRibZQCsHwouLZHeQ0MXHDykC/mUSOsBQCWDb6iGyaqqhW8rW4tQoLup6?=
 =?us-ascii?Q?oIq2kYZy29Is1parqAmQQsDUMPKMiUAPktbNP3QiXPg2xYom7Ib94pwMAzA+?=
 =?us-ascii?Q?3PAFI6iGsGI+B9Qy0Ybi60I3vMBRvAaciQpljj8b+NxRNXryCPQvaEqsVli4?=
 =?us-ascii?Q?PsOyz0Q0oqd3cEjtigMM+Oy79juBAoTdxqCPa8/GVOyTkU1Ywtp5x52xcNAy?=
 =?us-ascii?Q?bZ3ZGtQ2Komb4yKOhQsOB17w4X58QV1FvpbCroV1XUHZakMVnWF5E1i5lLBg?=
 =?us-ascii?Q?05MlhhrfdvHuQkcA2NUDuPcK5bVL7Kz4ULlY1hVp4SRqccgeklihe13fcL+s?=
 =?us-ascii?Q?gmHrSJ3b9cQUiBJn79RrWgcE95jm3+BWxkKTquP8efYqRah6KjiUnrlaCOiB?=
 =?us-ascii?Q?sC4bG52T7bdArEg21c5BoS4eZDsDR3MLAM5pQq0jjhhqpenORPWm54gUNnN+?=
 =?us-ascii?Q?433LjoDLkzD9Gx79o/OxLhBgUVGz4iFbbswfsHCLHhXW4F1qn9xY4NY4vl5T?=
 =?us-ascii?Q?UjTq3oZOg3TYWdw65I0JENsZ4/+UXpXgFY7l/QRvBK8JkelkjYsq50UhEYmv?=
 =?us-ascii?Q?DAK4UyFhHo4sR8+qs1BEVa5MNeWveckVjPtwPrci0X+n4Uy2tRJq2mV0FLXY?=
 =?us-ascii?Q?DikLUS/d375nHVZXhXSyZtTeHVV+++rPG3I8KCGEnbNUevajDmunXMI+UWb9?=
 =?us-ascii?Q?2g=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 942ff2f1-5e47-4162-f2ad-08db94941c1a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2023 02:40:05.2013
 (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: EGqx9A4lufp/9Bl5BF270D6YqZwnsupd1aFU1HN2WbiVqOExqMLKlHqsjB7Q68jFvVn0SqlEn2o+kdc/S4l2kxQOzXT1Rkb4gZBpC4SpI3s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7456
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jarkko Sakkinen wrote:
> On Mon Jul 31, 2023 at 7:33 PM EEST, Peter Gonda wrote:
> > What is the purpose of this report? What does it prove to whom? I'm a
> > bit confused because it doesn't seem like there is an ability for a
> > remote party to participate in a challenge and response to introduce
> > any freshness into this protocol.
> >
> > Also shouldn't the report have a little more context into the key we
> > are signing? For instance what type of public key is this? And what is
> > its purpose? In your example this isn't even a valid public key.
> 
> Yeah, I agree.
> 
> It is pretty hard to even evaluate whether this should be in kernel or
> could handled by the user space (perhaps with something less intrusive
> added to the kernel).
> 
> With cover letter starting with not one but two three letter acronyms
> that are not common vocabulary is already a red flag for me at least.
> 
> A lot more clarity is needed on what the heck this thing is anyway.

Apologies Jarkko, the assumption of this code was that because
drivers/virt/coco/sevguest.c was already exporting an ABI that put no
definition on the payload that this new key type would not need to
either.

However, your questioning proves the point that stashing security
relevant ABI in drivers/virt/coco/ is not a recipe to get worthwhile
review from security minded kernel practitioners.

So I can see why my explanation of "just do what sevguest was getting
away with" is not a great answer. Lets try again.

As mentioned in the AMD whitepaper [1]. Confidential computing has a use
case for a guest to prove to an attestation agent that it is running in
a valid configuration before that agent deploys other keys and secrets
to that VM to run a workload. One way to do that is to wrap a report of
the launch state of the VM with a public-key and if that report passes
validation use that key to send encrypted payloads back to the guest.

In this model the kernel is only a conduit to get 64-bytes of data
signed by the report, and the kernel need not have any requirements on
that data. That said, it could. That's where I would look to
recommendations from Dionna and James and others about what contract the
kernel *could*  enforce to ensure that best security practices are being
deployed.  I expect that also helps this implementation cross the
threshold from "blob store" to "key" as the Keyring expects.

[1]: Section "VM Launch & Attestation" https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf