From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D497BD2E3 for ; Wed, 28 Jun 2023 15:31:06 +0000 (UTC) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3fbab0d0b88so10538195e9.0 for ; Wed, 28 Jun 2023 08:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1687966265; x=1690558265; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=IfioyVtT4msXKVwBRY8hJRreQinRlAOTnCUWvwDS1Aw=; b=nry6CZib6BV+AVd9Jk+pSwezqKgJEVfCuLR1JPZqElVBafAbkTyVeLi23REdJ6UEpg 9stYvq8YgzwEPCHN9NTab2eV+iVMOW0i1JtZckyoqUkOqAK/pllmiGFsiJyi/bGGmj0g uY8ae0D2A0kbhPeOit3SFGY/QpNNcJRa7uQ1BDpqgpoEJczZvtp89ssBJzKc/kawnUOB atCKfE7Yoaxl9aqs3r2EGFKpxM5ILitcnFo+bBsy8auSHXE+0PmyupdqfDGMEBwziN/7 qAele+pj645BeJJh0/y4NqCqgdPy/Do3S/HEYa/GMX60Lj1lLqJlHYjmmAP0XDdGf4y/ bZzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687966265; x=1690558265; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IfioyVtT4msXKVwBRY8hJRreQinRlAOTnCUWvwDS1Aw=; b=hHUm2kAuSJ5F2asriNvn533P1lHcZ0NwSyIkL+peZ2hOKhQ0toJTQMkvx68wyW401f YRnq5CFizcBCGSgfTHhk2IYqobLKxbMu0noXbnAKOnMw0V+8E/zoFUv/TUAaUHgZkBW6 62kRnBNjTmiqiJgtVzPxt2/mRc0iuiJSUqdSxHHcDEpC8CsTlJWS60UPsF3d9FdMCHiM S0ihNOG5YZBq3sKxLJZT8G2pQYU4GXgqV75lamY8/vDh36VaNbg8iyU0H/WaRTwqAXuA 5GdNT4zAN04ZmOEXZ7k07AoPlrAW1+qSjmoovYmj8dUk9Cez7GJ+Hv6PNqeKpn0LFX+x aEaA== X-Gm-Message-State: ABy/qLbyF83mAs1RfCHVXbt71JGbhVI1xImkzDWSQ+DV9dmulNR4ENgz iSsrEfNzNtlYgfx2JYFYMRYmDA== X-Google-Smtp-Source: APBJJlEDnF97Eu/Q7rpDbn1H8DAMbx62dWdqkjaN8NPN/NE+nlQmuCQLftLd2qSWd/ZkLyHAStV++Q== X-Received: by 2002:a5d:544d:0:b0:314:1096:6437 with SMTP id w13-20020a5d544d000000b0031410966437mr1329640wrv.19.1687966264829; Wed, 28 Jun 2023 08:31:04 -0700 (PDT) Received: from vermeer ([2a01:cb1d:81a9:dd00:b570:b34c:ffd4:c805]) by smtp.gmail.com with ESMTPSA id w11-20020a5d608b000000b00313f7fc35e9sm6703755wrt.63.2023.06.28.08.31.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 08:31:04 -0700 (PDT) Date: Wed, 28 Jun 2023 17:31:01 +0200 From: Samuel Ortiz To: Dionna Amalie Glaze Cc: Dan Williams , Sathyanarayanan Kuppuswamy , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Shuah Khan , Jonathan Corbet , "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Wander Lairson Costa , Erdem Aktas , Chong Cai , Qinkun Bao , Guorui Yu , Du Fan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, dhowells@redhat.com, brijesh.singh@amd.com, atishp@rivosinc.com, gregkh@linuxfoundation.org, linux-coco@lists.linux.dev, joey.gouly@arm.com Subject: Re: [PATCH v3 3/3] selftests/tdx: Test GetQuote TDX attestation feature Message-ID: References: <972e1d5c5ec53e2757fb17a586558c5385e987dd.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com> <64876bf6c30e2_1433ac29415@dwillia2-xfh.jf.intel.com.notmuch> <64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch> <9437b176-e15a-3cec-e5cb-68ff57dbc25c@linux.intel.com> <649b7a9b69cb6_11e68529473@dwillia2-xfh.jf.intel.com.notmuch> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jun 27, 2023 at 06:36:07PM -0700, Dionna Amalie Glaze wrote: > On Tue, Jun 27, 2023 at 5:13 PM Dan Williams wrote: > > [..] > > > > > > The VMPL-based separation that will house the supervisor module known > > > as SVSM can have protocols that implement a TPM command interface, or > > > an RTMR-extension interface, and will also need to have an > > > SVSM-specific protocol attestation report format to keep the secure > > > chain of custody apparent. We'd have different formats and protocols > > > in the kernel, at least, to speak to each technology. > > > > That's where I hope the line can be drawn, i.e. that all of this vendor > > differentiation really only matters inside the kernel in the end. > > > > > I'm not sure it's worth the trouble of papering over all the... 3-4 > > > technologies with similar but still weirdly different formats and ways > > > of doing things with an abstracted attestation ABI, especially since > > > the output all has to be interpreted in an architecture-specific way > > > anyway. > > > > This is where I need help. Can you identify where the following > > assertion falls over: > > > > "The minimum viable key-server is one that can generically validate a > > blob with an ECDSA signature". > > > > I.e. the fact that SEV and TDX send different length blobs is less > > important than validating that signature. > > > > If it is always the case that specific fields in the blob need to be > > decoded then yes, that weakens the assertion. However, maybe that means > > that kernel code parses the blob and conveys that parsed info along with > > vendor attestation payload all signed by a Linux key. I.e. still allow > > for a unified output format + signed vendor blob and provide a path to > > keep all the vendor specific handling internal to the kernel. > > > > All the specific fields of the blob have to be decoded and subjected > to an acceptance policy. That policy will most always be different > across different platforms and VM owners. I wrote all of > github.com/google/go-sev-guest, including the verification and > validation logic, and it's going to get more complicated, and the > sources of the data that provide validators with notions of what > values can be trusted will be varied. The formats are not > standardized. The Confidential Computing Consortium should be working > toward that, but it's a slow process. There's IETF RATS. There's > in-toto.io attestations. There's Azure's JWT thing. There's a signed > serialized protocol buffer that I've decided is what Google is going > to produce while we figure out all the "right" formats to use. There > will be factions and absolute gridlock for multiple years if we > require solidifying an abstraction for the kernel to manage all this > logic before passing a report on to user space. I agree with most of the above, but all that nightmate^Wcomplexity is handled on the remote attestation side. If I understand the current discussion, it's about how to abstract a guest attestation evidence generation request in a vendor agnostic way. And I think what's proposed here is simply to pass a binary payload (The evidence request from the guest userspace) to the kernel key subsystem, hook it into vendor specific handler and get userspace an attestation evidence (a platform key signed blob) back to the guest app. The guest app can then give that to an attestation service, and that's when all the above described complexity takes place. Am I missing something? > Now, not only are the field contents important, the certificates of > the keys that signed the report are important. Each platform has its > own special x509v3 extensions and key hierarchy to express what parts > of the report should be what value if signed by this key, and in TDX's > case there are extra endpoints that you need to query to determine if > there's an active CVE on the associated TCB version. This is how they > avoid adding every cpu's key to the leaf certificate's CRL. > > You really shouldn't be putting attestation validation logic in the > kernel. AFAIU, that's not part of the proposal/PoC/mockup. It's all about funneling an attestation evidence request down to the TSM/PSP/firmware for it to generate an actually verifiable attestation evidence. Cheers, Samuel.