Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Message-ID: <78322d17-1fe7-4bfd-8073-64a7f0a1b0a2@amd.com>
Date:   Thu, 12 Oct 2023 22:18:27 +1100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/12] PCI device authentication
Content-Language: en-US
To:     Lukas Wunner <lukas@wunner.de>
Cc:     Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Bjorn Helgaas <helgaas@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Alex Williamson <alex.williamson@redhat.com>,
        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 <david.e.box@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        "Li, Ming" <ming4.li@intel.com>, Zhi Wang <zhi.a.wang@intel.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        Wilfred Mallawa <wilfred.mallawa@wdc.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Sean Christopherson <seanjc@google.com>,
        Alexander Graf <graf@amazon.com>
References: <cover.1695921656.git.lukas@wunner.de>
 <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch>
 <20231007100433.GA7596@wunner.de> <20231009123335.00006d3d@Huawei.com>
 <20231009134950.GA7097@wunner.de>
 <b003c0ca-b5c7-4082-a391-aeb04ccc33ca@amd.com>
 <20231012091542.GA22596@wunner.de>
From:   Alexey Kardashevskiy <aik@amd.com>
In-Reply-To: <20231012091542.GA22596@wunner.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dzgvZHVmNlA5MWxtdjV1THV6V1BiSUdHT2tQSWtmUWViNS9tWDZSY0w5bXky?=
 =?utf-8?B?aklWbExnMXFwMUVWUlR2RFBBNXp0dEN3TUVwOGtOQTlDV0RSdGtBT3FvenBU?=
 =?utf-8?B?OHgzKzRYN0pUNVNTRGFIbzRsRmJXa3hNYVo1WGhPS2JYRjB4cVRqdFc1eGE5?=
 =?utf-8?B?RWhkMmgrMmtUVDk2VzhnWEhqUlRvTTM1NkVtRlVTV1BaRmhybC8xNGxwY2pR?=
 =?utf-8?B?ZEpLU0pBUkYvOERDcGV2T0dPQndOU3lVYnFPS1lOcyt6VWI5aSs2d0RCMUt2?=
 =?utf-8?B?R1BsT1ZsQ0pkT3RieWI1aUM2cTFMQnVBTU1XajdVclltMmVzczkxMGZIUHl6?=
 =?utf-8?B?bXU0NnlNU29Ec2h5RmdrQlFiVERkZjBqdmpvbDZkdWJ3a0l6RUVFRWNuYzZ0?=
 =?utf-8?B?cmsvSitheVlRZkVqRDFUNFl0eDFUbHY3MFltM1NPbUZkek1tRUdKTlpDVkYy?=
 =?utf-8?B?UHlzRkNiSnM1UXdvNk1MKy8xdGh1QU4xNm8vajlCc01PeUFLSklyZHFGb1lz?=
 =?utf-8?B?QkNLa3Y1V1puUkN0U0NzZTIzYWIzOGtENmxjemkvdEpHL2ZLTCtJRERabDRY?=
 =?utf-8?B?RFBLZC9GZzl3YkNRWTloclIzbGxpMWxLT0FZODBueEhnZG1oS3lQVk1ZU1c1?=
 =?utf-8?B?TFFTb05QMzl0RVJVL1lVOTlCaEtDQ1FXSWNqMTRLa1VYb1N4blBQTEVNbGhT?=
 =?utf-8?B?VFlsZHYybEVIZGd2VEVicUxub0Raam5pNGxDejVSTVp4TVNXZDIwTWlUWDRX?=
 =?utf-8?B?RE45eUNhWllYZDEwMTBFOGxrNUxVNXhndk1NL2lSYXNtR1p5UU91TXYvZVdl?=
 =?utf-8?B?Y1hsRllKd3VkaWNhc3J6eUN5aTA2VTBvOXB3bU80WjBybUNiK01sZ3dOUG1V?=
 =?utf-8?B?NU1QNVhQZXlwV2dQeEttVVBJcmpLZWdTMUhISXUyRmZZTEVvL212eHYzTU55?=
 =?utf-8?B?MldBUUhrMTFrVjZuRlRPZmlha0ZkK1F1Y0RMeERpenAzZjlGd1JiVm5FUUN5?=
 =?utf-8?B?eFVKNTFLZzlZQlVFOGtxNjVGQ3lqR3hxSHNCV3JENXF1OUdqbDNMVitTWTA0?=
 =?utf-8?B?bUVtZVFHMG5kUUVPT1NKYUxSK0lrV2dZb3NHZENFYjVHaDd4amhOWUpOVkhp?=
 =?utf-8?B?MHh4Vkl1aEEwdFhJZUJBUnpDU1o1MVJxMmpFd1ZZSGx4NlFBK2NEbi9TaGZU?=
 =?utf-8?B?c1J0KzdEd0MxSUlZelAxNEFHT25jQVVXRUVCSTJSUFF3RXUyV0NBQUcxTEg3?=
 =?utf-8?B?clZUVnVkTkZ4RWxUSTFvN21kcTQ5V2VtSWRKUDRMMmZvQTBzdDNsL0hQTHhK?=
 =?utf-8?B?V2J5NFpGQlcyOTE3SnBPektYd1Y0dlBnNzJaTzFxdGh1RWlWanZoR0F6eCtm?=
 =?utf-8?B?dmV5NWU1dmVRQTJUMzJQK3R3SmJXVWZqNkpOR2hFTEI1dUU1MU1MSHUyVUJ0?=
 =?utf-8?B?TTRtV05zQmo0UDg2ZkM0Z3ZKejd4K3NKd09URFdnNW0wSTJ3VjBmb0JqNmlD?=
 =?utf-8?B?WjdQMHYxNmU2bVZabkF1RUtwY25FRnZ1VjNEdHJkNS91UVRHYzRJMXdXNkdK?=
 =?utf-8?B?aW5scFFBU1pTVVRPZmlYSzFWMGZDemdkVm1BeU04MVhTaS94MGJCNFVOeWJq?=
 =?utf-8?B?KzREZi9TSmxQcVlxZDBaa0Q1TDQ2aXhBRFp4R1Y1Zi9TUG4zdVZOYWovaTJ1?=
 =?utf-8?B?WnBCam5LSnFOTjFTZVVEU3ZTSlFSclMwWFNzV2tmcC9KY1BpVmcrQ1JZTUsy?=
 =?utf-8?B?NmxPN1ZQRnQ4UEFTTjFucW1VNXdFaHE2VmZ5bnpIZmJFNXdSQmQvNkFDNDIr?=
 =?utf-8?B?Tm5TSFByR0pwRkxzU3JzcCs5ZXZqZ1hwS01EcmVqd3MyMFQyMGxHYjM3TTJN?=
 =?utf-8?B?am9oT0Vxa2lFWGlEWCttSHY4NnJSSlRxdUJQNDJCUnBuWmNDZXVSaXBMeXNa?=
 =?utf-8?B?bGRWRXJqcWlBcloxdys1MVpBUEVyME1zSWlEc0k5TEV3UEwxYVgyL0NCY0Uw?=
 =?utf-8?B?OHMrMDNHUS9WWE9qaktZRjBmNUVqam9EbjVYTUFndGNpOTJudjJVSVA0T3hD?=
 =?utf-8?B?bHFtaEptMitFT0R2OURvSko4V3FqaGtUQklFdVJkdGsxcGF2a0ZDbDMxWTFH?=
 =?utf-8?Q?Kxf/9SjaAhadC2pfg8HXjmllS?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 112020a2-c472-43da-82bc-08dbcb150134
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB9194.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2023 11:18:48.1426
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1fe8NTZk6lbGLgyTbKgy7njlj5rE+T2UoCb0JM8uL7A4GMFfNzcnRZPR+52qhWD25ogE7mTwDQv+GQISynUGsA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8907
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 12 Oct 2023 04:19:05 -0700 (PDT)


On 12/10/23 20:15, 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?

Yes, to set up IDE. SEV TIO is designed in a way that there is one 
stream == set of keys per the PF's traffic class.

It is like this - imagine a TDISP+SRIOV device with hundreds VFs passed 
through to hundreds VMs. The host still owns the PF, provides DOE for 
the PSP, the PSP owns a handful of keys (one will do really, I have not 
fully grasped the idea when one would want traffic classes but ok, up to 
8), and hundreds VFs work using this few (or one) keys, and the PF works 
as well, just cannot know the IDE key (==cannot spy on VFs via something 
like PCI bridge/retimer or logic analyzer). It is different than what 
you are doing, DOE is the only common thing so far (or ever?).

btw the PSP is not able to initiate SPDM traffic by itself, when the 
host decides it wants to setup IDE (via a PSP in SEV TIO), it talks to 
the PSP which can return "I want to talk to the device, here are 
req/resp buffers", in a loop, until the PSP returns something else.

> 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.

Well, I'd expect that in most cases VF is going to be passed through and 
IDE setup is done via PF which won't be passed through in such cases as 
it has to manage VFs.

> So the host enumerates the DOE protocols

Yes.

> and authenticates the device.

No objection here. But PSP will need to rerun this, but still via the 
host's DOE.

> 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.

If a PF is passed through - I guess yes we could use that, but how is 
this going to work for a VF?

> I agree that the commit message of 12/12 is utterly misleading in that
> it says "the guest" is granted exclusive control.  It should say "the TSM"
> instead.  (There might be implementations where the guest itself has
> the role of the TSM and authenticates the device on its own behalf,
> but PCIe r6.1 sec 11 uses the term "TSM" so that's what the commit
> message needs to use.)

This should work as long as DOE is still available (as of today).

> However apart from the necessary rewrite of the commit message and
> perhaps a rename of the PCI_CMA_OWNED_BY_GUEST flag, I think patch 12/12
> should already be doing exactly what you need -- provided that the
> PSP doesn't perform SPDM exchanges before passthrough.  If it already
> performs them, say, on boot, I'd like to understand the reason.

In out design this does not have to happen on the host's boot. But I 
wonder if some PF host driver authenticated some device and then we 
create a bunch of VFs and pass the SPDM ownership of the PF to the PSP 
to reauthentificate it again - the already running PF host driver may 
become upset, may it? 12/12 assumes the host driver is VFIO-PCI but it 
won't be, VFs will be bound to VFIO-PCI. Hope this all makes sense. Thanks,


> 
> Thanks,
> 
> Lukas

-- 
Alexey