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, 28 Jul 2023 12:44:37 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jarkko Sakkinen <jarkko@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>, <dhowells@redhat.com>
CC:     Brijesh Singh <brijesh.singh@amd.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "Dionna Amalie Glaze" <dionnaglaze@google.com>,
        Borislav Petkov <bp@alien8.de>,
        Samuel Ortiz <sameo@rivosinc.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        <linux-coco@lists.linux.dev>, <keyrings@vger.kernel.org>,
        <x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports
Message-ID: <64c41aa5ba9ac_a88b29494@dwillia2-xfh.jf.intel.com.notmuch>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com>
 <CUE22P5RYPH3.1K05T2OCK1CN1@seitikki>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CUE22P5RYPH3.1K05T2OCK1CN1@seitikki>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tHF3gWQuP0+ZEku+l/bX+rhBEToNshfjifh24J9KdMTE6dDs7dEqRpbCev4v?=
 =?us-ascii?Q?g4h3YZ/cwsbtIz7TkQ2adxcqiKnelQaUQ7/B+K2a/GtRvfu/Dj9LVSRp3EQL?=
 =?us-ascii?Q?V9F6OyBRmLpIoXyOWPqvmx0KJPaKGJAXNZDIvqR2iO0kqFSMo2YQXY7EcCf9?=
 =?us-ascii?Q?kM6d0HUznb8kdOchQO5mRUOQxXIJun6nvG41JTT2uZISx7M6GvisqBxrtQJr?=
 =?us-ascii?Q?AbinyADUANcuHEr6A5x8JcSw7oKWLVnbqzZNdfgsYmDP0NVnDnZWI2VOxett?=
 =?us-ascii?Q?Ch4gojfs1T+6Ztal70OpKQPT0KWk5JOFnO9ahsuVXkbZplKuKoOOp7ZcTy1L?=
 =?us-ascii?Q?zgIp3ONCf168q4mRil3s5OeD7wMumcTDcJioosmdmYo38jnt9hZbXVZOWF02?=
 =?us-ascii?Q?uyrSBjY29tXuaS4pkTK1/TKMlXIbO9r87tHF+F3OMkxSoUuaEy2MWNcivkcb?=
 =?us-ascii?Q?aSra4UJCCmfP3QUr0ccSOy5jov3mrSWTHceD64GSR/vW6S2jzK+b+f5vcDS5?=
 =?us-ascii?Q?s2ZJAmGLYFe/dql4Pdey8IUwKQumBR/wz11pAaY+qClVKk852hv7h1AdDPn0?=
 =?us-ascii?Q?Anu38n9vt9n9dl/POwEPPmFxjz0kIC7BAyE8PQjx6R0UnQN9EePfqfsBv3vN?=
 =?us-ascii?Q?E+J6YA6R6fTTP74sudn5DWlZiwDz60o7VQfpuDMvOPdrp3G+KtxflJw/r4Ob?=
 =?us-ascii?Q?orNK+kJvEHv3wJB1lKEJ3LoFBwtOdfRFtYIUEgULlcOaJcJhzm194Ep1tvgQ?=
 =?us-ascii?Q?iB/rl82mrIhoIRk4Z0SebKW9P4l7YPeDvsmvvqbQLaeeMcVQoJRsW4diq2x3?=
 =?us-ascii?Q?RmUaQ6oQftvawLVMcGc0Gi1yhNs+9PB7U0J6Mu1h19iSSpFdM0GQGplMTVDi?=
 =?us-ascii?Q?Mmg4hiwc1nrSbU0UK7wn3tlPuzWWBOPIkGrOXm/BMPEZ8yqJ+vhaCUQpbnvW?=
 =?us-ascii?Q?xfWapGscXhldX16SVCfr+f68q34gM8ecDhOHUBoMXJD/QCU3BHfy/gtTvPQl?=
 =?us-ascii?Q?ytEK7/z3SLS8IBBqWFfjF3YRbr0v+si5mfBki29pIOzHLUFHpdDnOrejXbZC?=
 =?us-ascii?Q?faxRYi/KZ+2nfGifh8pfGgKD/A/euaupuYm86VBPnJblxmLMjaU+PD42PkC8?=
 =?us-ascii?Q?aFIghs60QEshAoE38ILuiC3Z+S/LKq+wBQ/h065mXh3RH/A6rDHlgd5gXOpj?=
 =?us-ascii?Q?5QK6FXSzu4I3C2Jkjs7H4xEzMSTNMcejvMbfTYHeqt6oM5Q7btBoiTSj64aT?=
 =?us-ascii?Q?rF6/P7QADrYDE52AmgyFu4T8u6RS2vRusoC+GYbl04JSV4KOCaoNkdxcb28/?=
 =?us-ascii?Q?nKOJAvjDFvNrgdTN+n7S2dsfFAe4uJPo7qIJKtl+nZsOXiVh8w1Nwc95M534?=
 =?us-ascii?Q?WR8E+srkwaugP+aujCOsV+lrAXgSPSwUWoM2S/OCYSL/C9eIX0Ybq6YQBZCP?=
 =?us-ascii?Q?WW4UbGh3LXACpUs46sXbyUJ4lDRNFFJFDeWCDFsmBSKgLCoxKN2iW1lvzNAn?=
 =?us-ascii?Q?vLzQZBjEv+4Spf+yivs3ZUMKcty3LSrRbO1RKqZvsRKlpm74njNLU9wHd7f6?=
 =?us-ascii?Q?OUyRwz/z9mIB7zR83tjB++Ks5UBocLUh1jyigqDacMPiM/ozHnIsF5GT1G6g?=
 =?us-ascii?Q?pg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e84de3a5-d6b5-4d20-84af-08db8fa3159e
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2023 19:44:40.9258
 (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: K7605YvniLXpXeXaeZa+MF8mcj1rl7QI8iyIODfvqbETlRVt1zEnzWgGXzCmW0VVi5/+ZOtu7CSyzXXyZG0vhfgcHXcl6JJUeHotCVPcnMw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5144
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,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 Fri Jul 28, 2023 at 7:30 PM UTC, Dan Williams wrote:
> > The bulk of the justification for this patch kit is in "[PATCH 1/4]
> 
> /patch kit/patch set/
> 
> > keys: Introduce tsm keys". The short summary is that the current
> > approach of adding new char devs and new ioctls, for what amounts to the
> > same functionality with minor formatting differences across vendors, is
> > untenable. Common concepts and the community benefit from common
> > infrastructure.
> >
> > Use Keys to build common infrastructure for confidential computing
> 
> /Keys/Linux keyring/
> 
> > attestation report blobs, convert sevguest to use it (leaving the
> > deprecation question alone for now), and pave the way for tdx-guest and
> > the eventual risc-v equivalent to use it in lieu of new ioctls.
> >
> > The sevguest conversion is only compile-tested.
> >
> > This submission is To:David since he needs to sign-off on the idea of a
> > new Keys type, the rest is up to the confidential-computing driver
> > maintainers to adopt.
> >
> > Changes from / credit for internal review:
> > - highlight copy_{to,from}_sockptr() as a common way to mix
> >   copy_user() and memcpy() paths (Andy)
> > - add MODULE_DESCRIPTION() (Andy)
> > - clarify how the user-defined portion blob might be used (Elena)
> > - clarify the key instantiation options (Sathya)
> > - drop usage of a list for registering providers (Sathya)
> > - drop list.h include from tsm.h (Andy)
> > - add a comment for how TSM_DATA_MAX was derived (Andy)
> > - stop open coding kmemdup_nul() (Andy)
> > - add types.h to tsm.h (Andy)
> > - fix punctuation in comment (Andy)
> > - reorder security/keys/Makefile (Andy)
> > - add some missing includes to tsm.c (Andy)
> > - undo an 81 column clang-format line break (Andy)
> > - manually reflow tsm_token indentation (Andy)
> > - move allocations after input validation in tsm_instantiate() (Andy)
> > - switch to bin2hex() in tsm_read() (Andy)
> > - move init/exit declarations next to their functions (Andy)
> >
> >
> > ---
> >
> > Dan Williams (4):
> >       keys: Introduce tsm keys
> >       virt: sevguest: Prep for kernel internal {get,get_ext}_report()
> >       mm/slab: Add __free() support for kvfree
> >       virt: sevguest: Add TSM key support for SNP_{GET,GET_EXT}_REPORT
> >
> >
> >  drivers/virt/coco/sev-guest/Kconfig     |    2 
> >  drivers/virt/coco/sev-guest/sev-guest.c |  135 ++++++++++++++-
> >  include/keys/tsm.h                      |   71 ++++++++
> >  include/linux/slab.h                    |    2 
> >  security/keys/Kconfig                   |   12 +
> >  security/keys/Makefile                  |    1 
> >  security/keys/tsm.c                     |  282 +++++++++++++++++++++++++++++++
> >  7 files changed, 494 insertions(+), 11 deletions(-)
> >  create mode 100644 include/keys/tsm.h
> >  create mode 100644 security/keys/tsm.c
> >
> > base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
> 
> So how does this scale? Does it scale to TDX, SGX, TPM's or even TEE's
> (ARM SM, RISC-V Keystone etc.). I'm not sure about the scope but we want
> of course something that adapts to multiple use cases, right?

TPMs and TEEs are covered by trusted-keys. I do think a "TSM" flavor of
trusted-keys is in scope for where some of these implementations are
headed, but that comes later. I talk about that in the changelog that
functionality like SNP_GET_DERIVED_KEY likely wants to have a
trusted-keys frontend and not isolated behind a vendor-specific ioctl
interface.

This facility is different, it is just aiming to unify this attestation
report flow. It scales to any driver that can provide the ->auth_new()
operation. I have the sev-guest conversion in this set, and Sathya has
tested this with tdx-guest. I am hoping Samuel can evaluate it for
cove-guest or whatever that driver ends up being called.