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:   Fri, 4 Aug 2023 15:24:24 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Peter Gonda <pgonda@google.com>,
        Dan Williams <dan.j.williams@intel.com>
CC:     <dhowells@redhat.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        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: <64cd7a98c68f8_2138e29496@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>
 <64c7f3df475d5_51ad02943f@dwillia2-xfh.jf.intel.com.notmuch>
 <CAMkAt6p9yEM7A5B9TyZsVTH=X=UQ3Z9wfYDg9etuc806mNdOiQ@mail.gmail.com>
 <64c80077d7144_51ad02941@dwillia2-xfh.jf.intel.com.notmuch>
 <CAMkAt6pPCJ0YsWaL692heDCUYjF9KCBq3PNiPK2LyBd=wD0+ig@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMkAt6pPCJ0YsWaL692heDCUYjF9KCBq3PNiPK2LyBd=wD0+ig@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ojJn4JAyC5nB8JCI6QigOKhdx7r1qO7vcQxNL5Gs7MAptg6qGJO8pm5QCd4Y?=
 =?us-ascii?Q?qJxjtfDLcII4WwsfuW0vTf4juoEEZgrgfDwU1iTFkVIu8ipoUJiC1HeoijNE?=
 =?us-ascii?Q?3x8MtfOyG6RV9AFjSkk+dCvG6T/Te0ZkatNhGnlguxGo6IeM6xy/GSOvehSa?=
 =?us-ascii?Q?Y5JyIQr9Uvrf5sRsA5Kw1+7cJ9eNp7XPrwNNxRmDE+qdQiENnYAZ8lyg+0gM?=
 =?us-ascii?Q?WqJz9pFldpVc6fMpIwJqSv9rkVDPXJzT1hSVASMpvwH6e4jyf2EZ0K6HIIPk?=
 =?us-ascii?Q?ITUpLr4z0D1Yr+JBMPIObgjZWEpDRtHJbsA5OuRx6z225qZt8lGmT3wy4B1T?=
 =?us-ascii?Q?qpH5A/IH3OvZazLkC69KiDhUaYckEHB8GC6iEWroBjxugvYMaPu9BkVUipul?=
 =?us-ascii?Q?bMSlCOHuDfxWV70nwGFj43xXZIljiyo73JnMnD/PVA7CPIl6LYhBMJ7YIRZJ?=
 =?us-ascii?Q?e2MPDV78wDaIOPa+kRRFKFjzxKpq6wa83putrzWyRRZpY/074oFZRF+I84tz?=
 =?us-ascii?Q?7a1rCZXIGK2eaRQo8e9EZcMYZBCJuOBNBadjT1Wyeq0qzDICIwpbctEIe1/9?=
 =?us-ascii?Q?iUBARHqSg4Q1n5vRz/FRhu1A8mwMSsREKre6QRkChOeNQRyMWIxOqdED/XT3?=
 =?us-ascii?Q?7OBdZ3n9e6CcxNnPy98IDvkaszBV6O2+efXJo5zb9P7Zw69TmZLBLe1Y6PCR?=
 =?us-ascii?Q?3nMerfbvxIVl3QeKY1ciB5NNgUmzPMVMg9Xq0vADSnB1pyWngvFnaXTENP2C?=
 =?us-ascii?Q?DTliZoyQsrcXVyb+UyUvQq2C0fjB1cY1dPuZ3K121mACTeRsiFep4cEQH2Uo?=
 =?us-ascii?Q?AbCc6wWmHzBI3gygsf/O1jbLoY0DIf5sPvo+whJnBePiz/3OocqM8Qwcn1rE?=
 =?us-ascii?Q?+BuZDHyJF1m3v08ehAGJmd9og5TRsIt23KXU525Z3PsqS13waWK8h9ij8tod?=
 =?us-ascii?Q?4u8kkorKVR6FCfla+jV6dqz4AjzM3fKje9fr+yQv/Sj4XBffkaBW/KXu7lGA?=
 =?us-ascii?Q?Bl/dUPLfslWH1lQY2lEzECVuE7WehsAlMs7wxhmaq23qivQ+3fGzvduv++Mj?=
 =?us-ascii?Q?mDpCSnswjZqwDinMWtrZNeSF8yw9fmR9TjZQZmSs4HsF7utXKjci3oc8s0Vb?=
 =?us-ascii?Q?ML1ZM9P+qrucdO+17t07slm1R8IQeGltFynn6498k40QO3/lus/LRtT6f1Gi?=
 =?us-ascii?Q?kYUwDdsVsxJGqxPMWYn309G/ugU3qqIVco/PetN7cpPeD+gHd6PmD4XyaK8j?=
 =?us-ascii?Q?AQAKTFD7xSVy/Fton3CzVFiHSkH2QclPAy7xg4YRlsBUBTmXSrL7QlvN+Pij?=
 =?us-ascii?Q?aA5MHed4k8a45ndMa0fQdCyJ8Oh+lD/xxRrg5UcRTUCIXW3LfvzYxh7W4P1p?=
 =?us-ascii?Q?+dNaNzGUAHvAGj/DHK1AShxlQTofBXEEJlgPX7HkUBzNMA8FDQwDEYPjBJ22?=
 =?us-ascii?Q?3ldjvOt9L7x6mWCDTQCEmXi66xX+cbKVh9I442WuG/G9JbrN5NROf1nTNgTj?=
 =?us-ascii?Q?TZoV6Uk0Se6JzFQ+R7KLy62JHJ7EoR2lT7TeelIcefQLHohBHonvsjUwrbHC?=
 =?us-ascii?Q?sPg809zcT2usA8E8xPaJA2tDJUlAQQIWdagBAMyLh68+IIJv7LECQaK+WhQf?=
 =?us-ascii?Q?vQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e59b276-3a2a-44fc-cf19-08db953990aa
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2023 22:24:27.7233
 (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: 6qAO7BL2NhI6RRTuuB+AQ1j/Fq3soMFymnnFyHBS0EbIWBdxdBUw5fVAdNvtMildgTTbz3it5l5biQV/t186H+xkT0xDSqwg3Geb/mhB1dI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB5963
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,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

Peter Gonda wrote:
> > > >
> > > > > > + * shared secret and then use that communication channel to instantiate
> > > > > > + * other keys. The expectation is that the requester of the tsm key
> > > > > > + * knows a priori the key-exchange protocol associated with the
> > > > > > + * 'pubkey'.
> > > > >
> > > > > Can we instead be very specific about what protocols and cryptography
> > > > > are being used?
> > > >
> > > > Again this is a contract to which the kernel is not a party. The
> > > > requester knows the significance of the user-data, and it knows where to
> > > > send the combined user-data plus quote to provision further secrets.
> > > >
> > > > Not that I like that arrangement, but the kernel is not enabled by these
> > > > TSM implementations to know much more than "user-data in", "report out".
> > >
> > > Can you explain why using this key API is better than the ioctl
> > > version? Is there an overhead to adding keys?
> >
> > Setting aside that folks that have been involved in the Keyring
> > subsystem a lot longer than I are not keen on this usage [1], I expect
> > the overhead is negligible. Keys are already used in RPC scenarios and
> > can be destroyed immediately after being instantiated and read.
> 
> OK the overhead is negligible. But why is this any better?
> 
> To me this seems strictly worse to me as a user since I have much less
> input into the hardware attestation which is one of the primary
> benefits of confidential compute. I don't want the kernel limiting
> what cryptographic algorithm I use, or limiting attestation reports to
> signing pubkeys.

The current proposal on the table is not to have the kernel enforce
anything with respect to the format of the "pubkey" payload. The only
feedback so far I have seen about improving the semantics here is
enforce a nonce which the ioctl() interface just has to trust userspace
is handling and the Keyring approach can enforce a callout for that
input.

> I understand having a proliferation of similar drivers may not be
> ideal but given the hardware lift required to make confidential
> compute happen will we really see too many?

From my perspective this discussion has already been worth it as some
people were unaware that security relevant development had started under
drivers/virt/coco/. The details of the kernel/user contract are coming
into focus.

In general, the point at which to have these types of discussions is at
the 1 -> 2 implementation transition, to my knowledge we are already up
to 5 of these things (AMD, Intel, RISC-V, ARM, S390).