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=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 E92DBC07E99 for ; Fri, 9 Jul 2021 01:37:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CABD061468 for ; Fri, 9 Jul 2021 01:37:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230217AbhGIBkX (ORCPT ); Thu, 8 Jul 2021 21:40:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229953AbhGIBkV (ORCPT ); Thu, 8 Jul 2021 21:40:21 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C579CC061760 for ; Thu, 8 Jul 2021 18:37:38 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id x3so3655489pfc.11 for ; Thu, 08 Jul 2021 18:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bZFu0LDbG95B1yaNBJ4fOjmqr6d8M46HMHg6GLetGXU=; b=xiDZEEYxruTTfQgL3aJXGO59DvjtJZObMOjVhV0sWjDcj17iafQLkdUmxo1ZSTVmqq hOhBbHdS08z+NS/vzPxqGEGqVYPRgWJvkts85BPJvK8rc4qls93ozI7b1mU3D7ftHLHa lRKvHtMRK4ld+oh1MKjaF/wv5C2u6ht+OCwoYTFE0Nq+8PdRMSesPZdnr6LAMjefcfT3 PDyrqH9mqO3aR2xv1s3hlxGss1SvpmSTTWaPeiSi5TGztoIA2Tc6OTHduB81a3alI0+t q1S9FpPVXSCUKoPVBguy200hSUDzhWXhtiQuTEaC8ZSgb+CDluoxriqvXGDMKvrxhKfk LixQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bZFu0LDbG95B1yaNBJ4fOjmqr6d8M46HMHg6GLetGXU=; b=L3pWy/DW1Jv1iRL5gVM68f+QwyEbmMBEhOSVQY9Lk5xI2QoKos+DfBKgq6/b4y2X7X j2ThA818kalwmHJ9NUQLxx1nblmRBsKbEzMzfcMD+ZLB3DwQzVL0pjtLflU3MUDFQYvW 5UDV2HdUD1wFZeypILk/Y2sci4kcsWzs35l0Mk8eRyREQLg/ntwKbM63ltoJVAr2WYCl lHVqVS/72YesUVeObBrjxf4bvB3AzG6VV9ePnz6Px+dwNQrx5Ud7ipLAKb/QHXNfZZy1 tNDjAOdShB3lQ5HjkTozB9LgRyxP4VLK32T+CrXdevFqqidujRqsdqiWYms/EyNXHUJL bV5w== X-Gm-Message-State: AOAM532nw++5xfQD0/LP8dgFaqc5ckoE2ySqKdixQ+sfl9E94zvcyjB1 Mi/TQDCDEPgHQhvQpFxgHmHGMQlvWPK2CP70EIZPPw== X-Google-Smtp-Source: ABdhPJxuJg/c8OhWhs8F8A3S/ckvZ0rDfon+3bRcdZtYFFx8C5h1oj5aEYTfw4sblldln9EwK8T/S11b0MOw0hSvnBQ= X-Received: by 2002:a05:6a00:22c4:b029:323:4955:a5d3 with SMTP id f4-20020a056a0022c4b02903234955a5d3mr17330045pfj.31.1625794657827; Thu, 08 Jul 2021 18:37:37 -0700 (PDT) MIME-Version: 1.0 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> <4972fc1a-1ffb-2b6d-e764-471210df96a3@linux.intel.com> In-Reply-To: <4972fc1a-1ffb-2b6d-e764-471210df96a3@linux.intel.com> From: Dan Williams Date: Thu, 8 Jul 2021 18:37:26 -0700 Message-ID: Subject: Re: [PATCH v2 5/6] platform/x86: intel_tdx_attest: Add TDX Guest attestation interface driver To: Andi Kleen Cc: "Kuppuswamy, Sathyanarayanan" , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 8, 2021 at 5:36 PM Andi Kleen wrote: > > > 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. One allocation for the life of the driver that can have its direct map permissions changed rather than an allocation per-file descriptor and fragmenting the direct map. > > 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) > Ok. I'll leave that alone for TDX, but I still have my eyes on keyutils for aspects of PCI SPDM.