From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFCDCC433ED for ; Thu, 20 May 2021 22:02:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 999E3610A8 for ; Thu, 20 May 2021 22:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231168AbhETWDl (ORCPT ); Thu, 20 May 2021 18:03:41 -0400 Received: from mga12.intel.com ([192.55.52.136]:49120 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230270AbhETWDl (ORCPT ); Thu, 20 May 2021 18:03:41 -0400 IronPort-SDR: IT1Xd+0wLmDiJN0IZHTaiMHIXvdkCbAOaS5qxOQRFeycmQo/lkyPQnECxzQwaxScQKxmKxPmYr Qrn3NcEhkJbw== X-IronPort-AV: E=McAfee;i="6200,9189,9990"; a="180954367" X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="180954367" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 15:02:19 -0700 IronPort-SDR: +aAe5WlQDqLOR+GbbEmM2f9botOQNm+eucww5GgQWidItvwmCQjLNIrVjc/06ldIyE8zSop1DT A4iVLvNkMByA== X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="475410755" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.197.177]) ([10.212.197.177]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2021 15:02:17 -0700 Subject: Re: [RFC PATCH 0/3] Allow access to confidential computing secret area To: "Dr. David Alan Gilbert" , Brijesh Singh Cc: Dov Murik , linux-efi@vger.kernel.org, Tobin Feldman-Fitzthum , Tobin Feldman-Fitzthum , Jim Cadden , James Bottomley , Hubertus Franke , Mike Rapoport , Laszlo Ersek , Ashish Kalra , Tom Lendacky , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210513062634.2481118-1-dovmurik@linux.ibm.com> <2c8ae998-6dd0-bcb9-f735-e90da05ab9d9@amd.com> From: Andi Kleen Message-ID: Date: Thu, 20 May 2021 15:02:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: On 5/20/2021 3:56 AM, Dr. David Alan Gilbert wrote: > * Brijes > The nice thing about Dov's device/file is that it's a simple text file > that userspace can then read the secret out of; I'm not sure if there's > anything similar in SNP (or for that matter TDX, cc'ing in Andi) In TDX there are two different mechanisms: - One is a ACPI table (SVKL) that allows to pass small pieces of data like keys from the BIOS. We have a little driver to read and clear the SVKL data. This would only be used if the TD BIOS does the negotiation for the secrets, which it doesn't do currently. - In the other model the negotiation is done by a user program, just using another driver to issue calls to the TDX module. The calls just expose the TDREPORT, which encodes the attestation data, but does not actually include any secret. Then the negotiation for the secrets is done by the program, which can then pass it out to other programs (like mount for encrypted file systems). In such a case the secret is never touched by the kernel. At least initially we'll use the second option. -Andi 57ccc1