From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 63CEE12B7C for ; Thu, 12 Oct 2023 13:13:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="lcOcjzVs" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-40651a726acso9553985e9.1 for ; Thu, 12 Oct 2023 06:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1697116414; x=1697721214; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IvfsuqeXvTAiiT0A6Kg2dLp8waVJkGZPJh+mIn+Z3lc=; b=lcOcjzVsM0Ht8LREIW46bWnTLt33b+Pgxfnbk1Cb4xYvbmK8krV1eW75Sqj2okshd6 b01Qv+bJ0R1NtOnVZU7lzT8mGAn+6G0CYkgV9CUo1B2TmLm/QlQaZ6cq5Ml7Xp1wu4Bp 383opHI+MZ+OM7bE+ht3mg1xVs3jxtl+dGcW4/22p75XE8vCj9/jSGbODChcmJ7VMnSS khoimbCiKh1kLIXhmWwX3PC3uf43kTJg7orTlDZKIDHmH7PWtUZUKPSsZprkFK7QiphS BflJeXU8LTq2/otQDQxRKpn6lxY5UZ3IFoLoaC1R3sPK1NgguFbYbiJMkOP2X8/luuti 7cAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697116414; x=1697721214; h=in-reply-to: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=IvfsuqeXvTAiiT0A6Kg2dLp8waVJkGZPJh+mIn+Z3lc=; b=gSzyzZb2sZJnwZDF3KgnOzliPmB/Dd87LSZd9Je3bk1p9Tqt+0KNrLbhpxRWZ/APBP wii+opEybmnTOAQllqqqdhVv7qiPrSy/SYwXSz5nSGISpHdPxgqihFibHJi7kj3Jcki7 zIacWXL4CSLS/2CrCYC8IBzIcjmT6maq52o4yjqroySCO61dbfUzmSHOPWxvUeONsjQ4 aKYzOxcVDwWG/4WXuXMYqyzHW/o14uSZCrzWLY8Qugd7WtgXlotuTy3UpXgSnUZBFdZn zgvZgPLY2KlHGf3l4llmdc6YunsRASdv3omsiJJoh5gzE3dyvNDrzwnXcxKzc/qZ065B 5n+g== X-Gm-Message-State: AOJu0YzIDz0Z3GOJYMNfOqqmdeG+GjYxAf86DDm0dheA1QWzjp3r7k63 FzYwTnLoe3ak3Fj97gHgD6jeTg== X-Google-Smtp-Source: AGHT+IFDkAeW7u7CFaRSTjjZPVGdE97IuC3OvNH39GloKvqqSstnsBhwBW7Tc7zhg48/jzIDrvVQig== X-Received: by 2002:a05:600c:255:b0:405:3d83:2b76 with SMTP id 21-20020a05600c025500b004053d832b76mr20973611wmj.13.1697116414527; Thu, 12 Oct 2023 06:13:34 -0700 (PDT) Received: from vermeer ([2a01:cb1d:81a9:dd00:b570:b34c:ffd4:c805]) by smtp.gmail.com with ESMTPSA id l17-20020a1ced11000000b0040588d85b3asm21637965wmh.15.2023.10.12.06.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 06:13:34 -0700 (PDT) Date: Thu, 12 Oct 2023 15:13:31 +0200 From: Samuel Ortiz To: Lukas Wunner Cc: Alexey Kardashevskiy , Jonathan Cameron , Dan Williams , Bjorn Helgaas , David Howells , David Woodhouse , Herbert Xu , "David S. Miller" , Alex Williamson , linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org, linux-coco@lists.linux.dev, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, kvm@vger.kernel.org, linuxarm@huawei.com, David Box , Dave Jiang , "Li, Ming" , Zhi Wang , Alistair Francis , Wilfred Mallawa , Tom Lendacky , Sean Christopherson , Alexander Graf Subject: Re: [PATCH 00/12] PCI device authentication Message-ID: References: <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch> <20231007100433.GA7596@wunner.de> <20231009123335.00006d3d@Huawei.com> <20231009134950.GA7097@wunner.de> <20231012091542.GA22596@wunner.de> 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=us-ascii Content-Disposition: inline In-Reply-To: <20231012091542.GA22596@wunner.de> On Thu, Oct 12, 2023 at 11:15:42AM +0200, Lukas Wunner wrote: > On Tue, Oct 10, 2023 at 03:07:41PM +1100, Alexey Kardashevskiy wrote: > > But the way SPDM is done now is that if the user (as myself) wants to let > > the firmware run SPDM - the only choice is disabling CONFIG_CMA completely > > as CMA is not a (un)loadable module or built-in (with some "blacklist" > > parameters), and does not provide a sysfs knob to control its tentacles. > > Kinda harsh. > > On AMD SEV-TIO, does the PSP perform SPDM exchanges with a device > *before* it is passed through to a guest? If so, why does it do that? SPDM exchanges would be done with the DSM, i.e. through the PF, which is typically *not* passed through to guests. VFs are. The RISC-V CoVE-IO [1] spec follows similar flows as SEV-TIO (and to some extend TDX-Connect) and expects the host to explicitly request the TSM to establish an SPDM connection with the DSM (PF) before passing one VF through a TSM managed guest. VFs would be vfio bound, not the PF, so I think patch #12 does not solve our problem here. > Dan and I discussed this off-list and Dan is arguing for lazy attestation, > i.e. the TSM should only have the need to perform SPDM exchanges with > the device when it is passed through. > > So the host enumerates the DOE protocols and authenticates the device. > When the device is passed through, patch 12/12 ensures that the host > keeps its hands off of the device, thus affording the TSM exclusive > SPDM control. Just to re-iterate: The TSM does not talk SPDM with the passed through device(s), but with the corresponding PF. If the host kernel owns the SPDM connection when the TSM initiates the SPDM connection with the DSM (For IDE key setup), the connection establishment will fail. Both CoVE-IO and SEV-TIO (Alexey, please correct me if I'm wrong) expect the host to explicitly ask the TSM to establish that SPDM connection. That request should somehow come from KVM, which then would have to destroy the existing CMA/SPDM connection in order to give the TSM a chance to successfully establish the SPDM link. Cheers, Samuel. [1] https://github.com/riscv-non-isa/riscv-ap-tee-io/blob/main/specification/07-theory_operations.adoc >