Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp2765672rwb; Sat, 29 Jul 2023 13:39:06 -0700 (PDT) X-Google-Smtp-Source: APBJJlEhMVa9vPiDjCBccLx+j5TB3C6oUhMd/qEOKQqfyWR+3E42bYbq1l6oVAnBWkIvnnoQCLHv X-Received: by 2002:a17:906:ef8f:b0:994:1844:549c with SMTP id ze15-20020a170906ef8f00b009941844549cmr2935436ejb.0.1690663146503; Sat, 29 Jul 2023 13:39:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690663146; cv=none; d=google.com; s=arc-20160816; b=YaTXVVa8raGOp8jbP1HlXChfZKULfVXfHmwvsjCx6c0s+e5SFHbaUwpGnkhgTIitfP wm4/0I53RQXy0DWnjhnxmLQpc+8l+Yj/7XAQstdPUDudtePLwv9qiY6v3rmjE6x6ERNm cGcEjZ3iI3OijFV3vPsDo6LHTGNM85U7OM3dwtm5TEvcj9KNu3Jqy5aDxYCmqFpOcQqs TCYb2yi7FY4HpWgJghPBQiGd7RcK3Vwjr7eevEpXsAq0Nbg1JfiSOlhtVIVwPN5ggA7l Ncw/J2iHpY6WY9dCWPloyplNLbFqtNaSDDwNU5dryJSpJ0NO9KwzagTRG7942NaWyClK qOJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature:dkim-signature; bh=VNmmLNuukeK8ifEC0vatFOPF2e39Ho12x/5dIpq1Kn4=; fh=T9YzyFmp/0+Hu5DXN6+wx3VfSVIut3L2KYwh4b5c/rQ=; b=qC+EwSGM95SKc0QlAxUnuE2XtEY548VAq+aAxt+/cxpjgIq5pilFWor2WvA7UDkGDR ctDne9UgUL/7C2ZgCkhPC0XmXuFUliMDGs8vgg91PuK9v6coW/mqriWlsCJzw5I2IWbJ 7orjRC1wPbUdikYk/e6vVZ5/QwIOfLtdoOMETqAW3MF575/TMzPzDKsQ+F7iz9rjpCvn 2NybsncGkkCbqJ58zIFhQZW2PTmXKAEV4fY+tiKsETw7jUd2ZJQoKb7M5Uddzq8CrKBx JX5suycm3Onac+SDm/LAaGlDyvW/S72SaoMesnNfORTV+9h15qsTbS2Z0tGAvNA3jlml Yeng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=r9ACkFQJ; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=r9ACkFQJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a7-20020aa7cf07000000b005223f8c7389si984754edy.240.2023.07.29.13.38.42; Sat, 29 Jul 2023 13:39:06 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=r9ACkFQJ; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=r9ACkFQJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229713AbjG2SRZ (ORCPT + 99 others); Sat, 29 Jul 2023 14:17:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbjG2SRY (ORCPT ); Sat, 29 Jul 2023 14:17:24 -0400 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB2A52723; Sat, 29 Jul 2023 11:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690654641; bh=h5IfinV0go2IJt6uz9MUW3cuAh/IHb80AxpLJZogiEA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r9ACkFQJbUkVzN2cXL4f5hHR2nJvxeh1m6dsqEk6p49m5mkyejozaDoB5abuVpTue RWpUHOaHrjTshCNLUBjF3Pu4n38tdgoahXYxhPAOPlGEbKF3rzk+bCaTR/yAd6hvX3 /GaKZ8OaAmjYY3k9XUI6zQT1tQ2TUKXJ3UL4EeFQ= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 36D7B1281747; Sat, 29 Jul 2023 14:17:21 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id cMMexv2ufveb; Sat, 29 Jul 2023 14:17:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690654641; bh=h5IfinV0go2IJt6uz9MUW3cuAh/IHb80AxpLJZogiEA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r9ACkFQJbUkVzN2cXL4f5hHR2nJvxeh1m6dsqEk6p49m5mkyejozaDoB5abuVpTue RWpUHOaHrjTshCNLUBjF3Pu4n38tdgoahXYxhPAOPlGEbKF3rzk+bCaTR/yAd6hvX3 /GaKZ8OaAmjYY3k9XUI6zQT1tQ2TUKXJ3UL4EeFQ= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::a774]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id BE7A01281269; Sat, 29 Jul 2023 14:17:19 -0400 (EDT) Message-ID: Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports From: James Bottomley To: Dan Williams , dhowells@redhat.com Cc: Brijesh Singh , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Tom Lendacky , Dionna Amalie Glaze , Borislav Petkov , Jarkko Sakkinen , Samuel Ortiz , Greg Kroah-Hartman , Andrew Morton , linux-coco@lists.linux.dev, keyrings@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Date: Sat, 29 Jul 2023 14:17:18 -0400 In-Reply-To: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2023-07-28 at 12:30 -0700, Dan Williams wrote: > The bulk of the justification for this patch kit is in "[PATCH 1/4] > 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. I agree with this, but ... > Use Keys to build common infrastructure for confidential computing > 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. So why is this a keys subsystem thing? The keys in question cannot be used to do any key operations. It looks like a transport layer for attestation reports rather than anything key like. To give an analogy with the TPM: We do have a TPM interface to keys because it can be used for things like sealing (TPM stores a symmetric key) and even asymmetric operations (although TPM key support for that in 1.2 was just removed). However, in direct analogy with confidential computing: the TPM does have an attestation interface: TPM2_Quote and TPM2_Certify (among others) which is deliberately *not* wired in to the keys subsystem because the outputs are intended for external verifiers. If the goal is to unify the interface for transporting attestation reports, why not pull the attestation ioctls out of sevguest into something common? I also don't see in your interface where the nonce goes? Most attestation reports combine the report output with a user supplied nonce which gets added to the report signature to defend against replay. Finally, I can see the logic in using this to do key release, because the external relying entity usually wishes to transport secrets into the enclave, but the currently developing use case for that seems to be to use a confidential guest vTPM because then we can use the existing TPM disk key interfaces. Inventing something completely new isn't going to fly because all consumers have to be updated to use it (even though keys is a common interface, using key payloads isn't ... plus the systemd TPM disk encryption key doesn't even use kernel keys, it unwraps in userspace). James