Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp154397pxv; Thu, 8 Jul 2021 17:38:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5f/G9qbVwz1wfIr6Q6ULTd62iqGDjdW63aC7TNDJ1CCGd3YOMut41Lw3lG6KIkDn3hb6K X-Received: by 2002:a05:6402:4408:: with SMTP id y8mr42809299eda.55.1625791119760; Thu, 08 Jul 2021 17:38:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625791119; cv=none; d=google.com; s=arc-20160816; b=a0Os+fcQaxGqVZzhk8P8s7lEX9jT6YPQhhXkcBLi1EaOsAKa6JlMuCPoNVOM6L0hh4 M/fw5V3k7k3YFLEcalHqo6iU0Jx5y+YfIo4FbwiQ5o0ipa39f+nltDA7Z8kF7ILyHpeX 3BANd7heqKneug0M0zLMLb8FLfQcvqP0TzMKTnbC1cduZKz7BcICxBgPFJcmSpAIWov3 P8btF2j3+iZLX4kY4Ri1LZGc/Nx6TaqS00xrpebNj8NkRqrFJsEwO0a1rDBBGvnD+5PG iuwAfSszixKOUZnFr63tj1wSKKUn1Dps8+Vt20QCoAQCkRcN1KNmgitVXTB6F6ctqoLN zCnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=k6N+kH2XqBc3oUZvPZ1EbuCkaRYqoRR2rHfl1egvGGo=; b=Xzknfg6Q7xVeVoUEnRuaxvSNUoiTXc5WwtnFDA/Fm3pdoNPX8kMuXI/SaBwk6y5I9H e4z16hFFh+rUXHdpk3DGFMMlTen1WWIWaRQtxt1oHxWB5Tf0i0SCZJYd22/ngFEaxFDh mtoGKCB7KfpPx4WiOjQN97mYnGg14aktnbIPX2gN8JfPFn2/dmqpCbZwa6JUT0XcNc+Q Wd6410EZYHpw7axMkLqgipiWlHvnvBEQ2YRslugUr6l+IyjE2YS/NF8yAP7ahRpHdKt+ 5wz0kxiQUo51K0Mh1Ki1cXZWWwTLsks1msrgXADayflQ2Ce9IDXATWyFeY6QOZfviza7 NLWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ca9si4677322edb.172.2021.07.08.17.38.14; Thu, 08 Jul 2021 17:38:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230234AbhGIAj2 (ORCPT + 99 others); Thu, 8 Jul 2021 20:39:28 -0400 Received: from mga14.intel.com ([192.55.52.115]:39326 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229637AbhGIAj2 (ORCPT ); Thu, 8 Jul 2021 20:39:28 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10039"; a="209440428" X-IronPort-AV: E=Sophos;i="5.84,225,1620716400"; d="scan'208";a="209440428" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2021 17:36:45 -0700 X-IronPort-AV: E=Sophos;i="5.84,225,1620716400"; d="scan'208";a="458088595" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.178.170]) ([10.212.178.170]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2021 17:36:44 -0700 Subject: Re: [PATCH v2 5/6] platform/x86: intel_tdx_attest: Add TDX Guest attestation interface driver To: Dan Williams , "Kuppuswamy, Sathyanarayanan" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Hans de Goede , Mark Gross , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Peter H Anvin , Dave Hansen , Tony Luck , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , X86 ML , Linux Kernel Mailing List , platform-driver-x86@vger.kernel.org, bpf@vger.kernel.org, Netdev References: <20210707204249.3046665-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20210707204249.3046665-6-sathyanarayanan.kuppuswamy@linux.intel.com> <24d8fd58-36c1-0e89-4142-28f29e2c434b@linux.intel.com> From: Andi Kleen Message-ID: <4972fc1a-1ffb-2b6d-e764-471210df96a3@linux.intel.com> Date: Thu, 8 Jul 2021 17:36:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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: X-Mailing-List: linux-kernel@vger.kernel.org On 7/8/2021 5:20 PM, Dan Williams wrote: > > If you have a lock would TDX KVM even notice that its parallel > requests are being handled serially? I.e. even if they said "yes, > multiple requests may happen in parallel", until it becomes an actual > latency problem in practice it's not clear that this generous use of > resources is justified. The worst case usage is 2 pages * file descriptor. There are lots of other ways to use that much and more memory for each file descriptor. > > Scratch that... this driver already has the attestation_lock! So, it's > already the case that only one thread can be attesting at a time. The > per-file buffer is unecessary. But then you couldn't free the buffer. So it would be leaked forever for likely only one attestation. Not sure what problem you're trying to solve here. > > keyutils supports generating and passing blobs into and out of the > kernel with a handle associated to those blobs. This driver adds a TDX > way to pass blobs into and out of the kernel. If Linux grows other > TDX-like attestation requirements in the future (e.g. PCI SPDM) should > each of those invent their own user ABI for passing blobs around? The TDX blobs are different than any blobs that keyutils supports today. The TDX operations are different too. TDREPORT doesn't even involve any keys, it's just attestation reports. keyutils today nothing related to attestation. I just don't see any commonality. If there was commonality it would be more with the TPM interface, but TDX attestation is different enough that it also isn't feasible to directly convert it into TPM operation (apart from standard TPM being a beast that you better avoid as much as possible anyways) -Andi