Message ID | 169199898909.1782217.10899362240465838600.stgit@dwillia2-xfh.jf.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp2594250vqi; Mon, 14 Aug 2023 01:15:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHj1e2PLqCM8lP2Pg06yqeXnFIt8mU/IuZHr0tKg2459f89l2UFsdvLrQlgo3TZn5Kr0uPr X-Received: by 2002:a05:6808:1382:b0:3a3:ed69:331 with SMTP id c2-20020a056808138200b003a3ed690331mr10719216oiw.6.1692000913901; Mon, 14 Aug 2023 01:15:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692000913; cv=none; d=google.com; s=arc-20160816; b=kAUVey7JbWvmhkKqnvud3oQk6ztm8Wd0ZgN37AsigdSx6emq+CdkT/wLkS03MVyFTk 6Vn/3B1IUkEV16jebDK1GUXLVeBa1R8f+YGtH2nmqA/mqv/ptO69QYZuIDYU5YliHbkB w1HiIkUaYCZsuv6KP8ZDSiUvorwoJ9DWt2uxLhGdh6aeFMF2rublg3twCTfJ5mcTrF7B KCk3bRx95Zp1J8bdG8DvYom4yIud3gt3Gje105FNfDFehvetYd3jR0dS4NMfUX7/cRIk XOMH5woyKr6Iqb76woH9GNMcOeeMEqK2tB/iqgKpGKxH3VZmUPCq7cn8dmnb1k4LPZMq gKxQ== 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:message-id:date:cc:to:from:subject:dkim-signature; bh=p5cUcT8wF77nf9iUrPEtHcBi6LnhhdGp0Ic679lQZSw=; fh=2F7FVv8GMqp0tO+vCQlAEioeqfrIQhbhovvdp6tJw6s=; b=Ew1r/Uo+MiKzrDBZg/iYN/DnYevRhatc8PlvlZEYARrbOqMkAgfw+YpeXPNjOhsQ9C V5ORHGl7VsJtFiR6OS6BzdkJ4t2FHiicqgUouXL1fsntw3010Lhq9FPd/fbobQRf6JCc 7ENgARgA22TK1A2qaVri9YqO16ibUJufx2v7w8jMmEKiUgF/Qlgf+dSZTprXBmzaWeuc +4r0luLItqs9m1+MHGWGYsMKEbdDCaII271ncZXFLKpiVk4/xOJ9xFjKLsU4gFevdOy4 iNz8Xohkks77+iTobrB0y3TEWf3jKjQJTsw2Z7bZJo48LB3IF3TaNF4jl5w5FuwovDE8 biPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PChgSSfF; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b10-20020a630c0a000000b00563ef54582bsi7670009pgl.105.2023.08.14.01.14.59; Mon, 14 Aug 2023 01:15:13 -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=@intel.com header.s=Intel header.b=PChgSSfF; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234153AbjHNHnp (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Mon, 14 Aug 2023 03:43:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234339AbjHNHnL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 14 Aug 2023 03:43:11 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E91BC115 for <linux-kernel@vger.kernel.org>; Mon, 14 Aug 2023 00:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691998990; x=1723534990; h=subject:from:to:cc:date:message-id:mime-version: content-transfer-encoding; bh=TwoF5fq59lRt7vlTdgDePaChbL1k3CWvyUQLNnCPZ/s=; b=PChgSSfFONf5HgCMJjgsaKJywC7ChfzxxMIdjYPwhbZgq+PIDtxf2w/F XSvHeEZN2ZaClinOe+Z2u4qqQlqbquKZIYd1T1DZBikhvEAFJFHVkhUqw v7qTNQIG41SMhWPNA2b7oSyXMjK3S0bdIxNGd4ws0/omgQkdUuEWGnyod iRx2qQNZEWqN3e6VWIxImgiu2X/nM3cL8tvOWxTpppdkO2cflAL163U33 /7hrNMJfKMhgjVAY0e3HR5CGXsjCij2tKGNUkl6vqTHYjSFFunPwc1NCb g7VAjCkr0SkoteeHG/pi9rG8QyuuUSbM6ikx2ftdLlEpYsBMi9/HakH6f w==; X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="370882719" X-IronPort-AV: E=Sophos;i="6.01,172,1684825200"; d="scan'208";a="370882719" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2023 00:43:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="736445226" X-IronPort-AV: E=Sophos;i="6.01,172,1684825200"; d="scan'208";a="736445226" Received: from navanban-mobl.amr.corp.intel.com (HELO dwillia2-xfh.jf.intel.com) ([10.209.127.25]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2023 00:43:09 -0700 Subject: [PATCH v2 0/5] tsm: Attestation Report ABI From: Dan Williams <dan.j.williams@intel.com> To: linux-coco@lists.linux.dev 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>, Peter Gonda <pgonda@google.com>, Borislav Petkov <bp@alien8.de>, Dionna Amalie Glaze <dionnaglaze@google.com>, Samuel Ortiz <sameo@rivosinc.com>, Dionna Glaze <dionnaglaze@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andrew Morton <akpm@linux-foundation.org>, James Bottomley <James.Bottomley@HansenPartnership.com>, x86@kernel.org, linux-kernel@vger.kernel.org Date: Mon, 14 Aug 2023 00:43:09 -0700 Message-ID: <169199898909.1782217.10899362240465838600.stgit@dwillia2-xfh.jf.intel.com> User-Agent: StGit/0.18-3-g996c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774191549827980052 X-GMAIL-MSGID: 1774191549827980052 |
Series |
tsm: Attestation Report ABI
|
|
Message
Dan Williams
Aug. 14, 2023, 7:43 a.m. UTC
Changes since v1: - Switch from Keyring to sysfs (James) An attestation report is signed evidence of how a Trusted Virtual Machine (TVM) was launched and its current state. A verifying party uses the report to make judgements of the confidentiality and integrity of that execution environment. Upon successful attestation the verifying party may, for example, proceed to deploy secrets to the TVM to carry out a workload. Multiple confidential computing platforms share this similar flow. The approach of adding adding new char devs and new ioctls, for what amounts to the same logical functionality with minor formatting differences across vendors [1], is untenable. Common concepts and the community benefit from common infrastructure. Use sysfs for this facility for maintainability compared to ioctl(). The expectation is that this interface is a boot time, configure once, get report, and done flow. I.e. not something that receives ongoing transactions at runtime. However, runtime retrieval is not precluded and a mechanism to detect potential configuration conflicts from multiple-threads using this interface is included. The keyring@ list is dropped on this posting since a new key-type is no longer being pursued. Link: http://lore.kernel.org/r/cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com --- Dan Williams (5): virt: coco: Add a coco/Makefile and coco/Kconfig tsm: Introduce a shared ABI for attestation reports virt: sevguest: Prep for kernel internal {get,get_ext}_report() mm/slab: Add __free() support for kvfree virt: sevguest: Add TSM_REPORTS support for SNP_{GET,GET_EXT}_REPORT Documentation/ABI/testing/sysfs-class-tsm | 47 +++++ MAINTAINERS | 8 + drivers/virt/Kconfig | 6 - drivers/virt/Makefile | 4 drivers/virt/coco/Kconfig | 13 + drivers/virt/coco/Makefile | 8 + drivers/virt/coco/sev-guest/Kconfig | 1 drivers/virt/coco/sev-guest/sev-guest.c | 129 ++++++++++++- drivers/virt/coco/tdx-guest/Kconfig | 1 drivers/virt/coco/tsm.c | 290 +++++++++++++++++++++++++++++ include/linux/slab.h | 2 include/linux/tsm.h | 45 +++++ 12 files changed, 535 insertions(+), 19 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-tsm create mode 100644 drivers/virt/coco/Kconfig create mode 100644 drivers/virt/coco/Makefile create mode 100644 drivers/virt/coco/tsm.c create mode 100644 include/linux/tsm.h base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
Comments
On 8/14/2023 9:43 AM, Dan Williams wrote: > Changes since v1: > - Switch from Keyring to sysfs (James) > > An attestation report is signed evidence of how a Trusted Virtual > Machine (TVM) was launched and its current state. A verifying party uses > the report to make judgements of the confidentiality and integrity of > that execution environment. Upon successful attestation the verifying > party may, for example, proceed to deploy secrets to the TVM to carry > out a workload. Multiple confidential computing platforms share this > similar flow. > > The approach of adding adding new char devs and new ioctls, for what > amounts to the same logical functionality with minor formatting > differences across vendors [1], is untenable. Common concepts and the > community benefit from common infrastructure. > > Use sysfs for this facility for maintainability compared to ioctl(). The > expectation is that this interface is a boot time, configure once, get > report, and done flow. I.e. not something that receives ongoing > transactions at runtime. However, runtime retrieval is not precluded and > a mechanism to detect potential configuration conflicts from > multiple-threads using this interface is included. > I wanted to speak up to say that this does not align with the needs we have in the Confidential Containers project. We want to be able to perform attestation not just once during boot but during the lifecycle of the confidential VM. We may need to fetch a fresh attestation report from a trusted agent but also from arbitrary applications running in containers. The trusted agent might need attestation when launching a new container from an encrypted container image or when a new secret is being added to the VM - both of these events may happen at any time (also when containerized applications are already executing). Container applications have their own uses for attestation, such as when they need to fetch keys required to decrypt payloads. We also have things like performing attestation when establishing a TLS or ssh connection to provide an attested e2e encrypted communication channel. I don't think sysfs is suitable for such concurrent transactions. Also if you think about exposing the sysfs interface to an application in a container, this requires bind mounting rw part of the sysfs tree into the mount namespace - not ideal. Jeremi > The keyring@ list is dropped on this posting since a new key-type is no > longer being pursued. > > Link: http://lore.kernel.org/r/cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com > > --- > > Dan Williams (5): > virt: coco: Add a coco/Makefile and coco/Kconfig > tsm: Introduce a shared ABI for attestation reports > virt: sevguest: Prep for kernel internal {get,get_ext}_report() > mm/slab: Add __free() support for kvfree > virt: sevguest: Add TSM_REPORTS support for SNP_{GET,GET_EXT}_REPORT > > > Documentation/ABI/testing/sysfs-class-tsm | 47 +++++ > MAINTAINERS | 8 + > drivers/virt/Kconfig | 6 - > drivers/virt/Makefile | 4 > drivers/virt/coco/Kconfig | 13 + > drivers/virt/coco/Makefile | 8 + > drivers/virt/coco/sev-guest/Kconfig | 1 > drivers/virt/coco/sev-guest/sev-guest.c | 129 ++++++++++++- > drivers/virt/coco/tdx-guest/Kconfig | 1 > drivers/virt/coco/tsm.c | 290 +++++++++++++++++++++++++++++ > include/linux/slab.h | 2 > include/linux/tsm.h | 45 +++++ > 12 files changed, 535 insertions(+), 19 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-tsm > create mode 100644 drivers/virt/coco/Kconfig > create mode 100644 drivers/virt/coco/Makefile > create mode 100644 drivers/virt/coco/tsm.c > create mode 100644 include/linux/tsm.h > > base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
On Mon, Aug 14, 2023 at 11:12 AM Dan Williams <dan.j.williams@intel.com> wrote: > > Jeremi Piotrowski wrote: > > On 8/14/2023 9:43 AM, Dan Williams wrote: > > > Changes since v1: > > > - Switch from Keyring to sysfs (James) > > > > > > An attestation report is signed evidence of how a Trusted Virtual > > > Machine (TVM) was launched and its current state. A verifying party uses > > > the report to make judgements of the confidentiality and integrity of > > > that execution environment. Upon successful attestation the verifying > > > party may, for example, proceed to deploy secrets to the TVM to carry > > > out a workload. Multiple confidential computing platforms share this > > > similar flow. > > > > > > The approach of adding adding new char devs and new ioctls, for what > > > amounts to the same logical functionality with minor formatting > > > differences across vendors [1], is untenable. Common concepts and the > > > community benefit from common infrastructure. > > > > > > Use sysfs for this facility for maintainability compared to ioctl(). The > > > expectation is that this interface is a boot time, configure once, get > > > report, and done flow. I.e. not something that receives ongoing > > > transactions at runtime. However, runtime retrieval is not precluded and > > > a mechanism to detect potential configuration conflicts from > > > multiple-threads using this interface is included. > > > > > > > I wanted to speak up to say that this does not align with the needs we have > > in the Confidential Containers project. We want to be able to perform attestation > > not just once during boot but during the lifecycle of the confidential VM. We > > may need to fetch a fresh attestation report from a trusted agent but also from > > arbitrary applications running in containers. > > > > The trusted agent might need attestation when launching a new container from an > > encrypted container image or when a new secret is being added to the VM - both > > of these events may happen at any time (also when containerized applications > > are already executing). > > > > Container applications have their own uses for attestation, such as when they need > > to fetch keys required to decrypt payloads. We also have things like performing > > attestation when establishing a TLS or ssh connection to provide an attested e2e > > encrypted communication channel. > > ...and you expect that the boot time attestation becomes invalidated > later at run time such that ongoing round trips to the TSM are needed? I > am looking at "Table 21. ATTESTATION_REPORT Structure" for example and > not seeing data there that changes from one request to the next. Runtime > validation likely looks more like the vTPM use case with PCRs. That will > leverage the existing / common TPM ABI. I thought we were dropping the TSM acronym as requested by Jarkko? Why do we need to be so prescriptive about "boot time" vs "runtime" attestations? A user may wish to attest to several requests as Jeremi notes. And why should users be forced into using a vTPM interface if their usecase doesn't require all the features and complexity of a vTPM? Some users may prefer less overall code within their Trusted Computer Base (TCB) and a TPM emulate is a significant code base. It seems like you are just reading the SNP spec, if you read the TDX spec you'll see there are RTMRs which can be extended with new data. This leads to a different data in the attestation. Similar there are REMs in the ARM CCA spec. > > > I don't think sysfs is suitable for such concurrent transactions. Also if you think > > about exposing the sysfs interface to an application in a container, this requires > > bind mounting rw part of the sysfs tree into the mount namespace - not ideal. > > sysfs is not suitable for concurrent transactions. The container would > need to have an alternate path to request that the singleton owner of > the interface generate new reports, or use the boot time attestation to > derive per container communication sessions to the attestation agent.