On Tue, Feb 28, 2023 at 06:24:41PM +1100, Alexey Kardashevskiy wrote: > On 28/2/23 16:43, Lukas Wunner wrote: > > On Tue, Feb 28, 2023 at 12:18:07PM +1100, Alexey Kardashevskiy wrote: > > > On 11/2/23 07:25, Lukas Wunner wrote: > > > > For the same reason a DOE instance cannot be shared between the > > > > PCI core and a driver. > > > > > > And we want this sharing why? Any example will do. Thanks, > > > > The PCI core is going to perform CMA/SPDM authentication when a device > > gets enumerated (PCIe r6.0 sec 6.31). That's the main motivation > > to lift DOE mailbox creation into the PCI core. It's not mentioned > > here explicitly because I want the patch to stand on its own. > > CMA/SPDM support will be submitted separately. > > I was going the opposite direction with avoiding adding this into the PCI > core as 1) the pci_dev struct is already 2K and 2) it is a niche feature > and 3) I wanted this CMA/SPDM session setup to be platform specific as on > our platform the SPDM support requires some devices to be probed before we > can any SPDM. We had an open discussion at Plumbers with stakeholders from various companies and the consensus was that initially we'll upstream a CMA/SPDM implementation which authenticates devices on enumeration and exposes the result to user space via sysfs. Nothing more, nothing less: https://lpc.events/event/16/contributions/1304/ https://lpc.events/event/16/contributions/1304/attachments/1029/1974/LPC2022-SPDM-BoF-v4.pdf Thereby we seek to minimize friction in the upstreaming process because we avoid depending on PCIe features layered on top of CMA/SPDM (such as IDE) and we can postpone controversial discussions about the consequences of failed authentication (such as forbidding driver binding or firewalling the device off via ACS). The patches under development follow the approach we agreed on back then. I honestly think that the size of struct pci_dev is a non-issue because even the lowest-end IoT devices come with gigabytes of memory these days and as long as we do not exceed PAGE_SIZE (which is the limit when we'd have to switch from kmalloc() to vmalloc() I believe), there's no problem. The claim that DOE and CMA/SPDM is going to be a niche feature is at least debatable. It seems rather likely to me that we'll see adoption particularly in the mobile segment as iOS/Android/Chrome promulgators will see an opportunity to harden their products further. It's intriguing that you need some devices to be probed before you can perform authentication. What do you need this for? Do you perhaps need to load firmware onto the device before you can authenticate it? Doesn't that defeat the whole point of authentication? Or do you mean that certain *other* devices need to probe before a device can be authenticated? What are these other devices? What happens if the device is suspended to D3cold or experiences a Conventional Reset? Do you need to do anything special before you can re-authenticate the device? On the one hand, performing authentication in the PCI core could be considered a case of midlayer fallacy. On the other hand, I think we do want to afford CMA/SPDM and the features layered on top of it (IDE, TDISP) regardless whether a driver is bound: That way we can protect the PCI core's communication with the device and with ACS we can protect other PCI devices in the system from peer-to-peer communication originating from a malicious device which failed to authenticate. I would like to make the implementation under development work for your use case as well, but to do that I need a better understanding what your requirements are. Thanks, Lukas
