On Jun 10, 2024, at 10:42 PM, Alistair Francis <alistair23@gmail.com> wrote:
Hello,
I'm trying to use SPDM over DOE as a EDKII_DEVICE_SECURITY_PROTOCOL
implementation.
I'm using the DeviceSecurity fork from staging, with my own DOE
implementation [5].
First I load `DeviceSecurityPolicyStub` [1], which consumes
`gEdkiiDeviceIdentifierTypePci
Guid` and produces
`gEdkiiDeviceSecurityPolicyProtocolGuid`.
Then I am loading `SpdmDeviceSecurityDxe` [2], which consumes
`gEdkiiDeviceSecurityPolicyProtocolGuid` and produces
`gEdkiiDeviceSecurityProtocolGuid`.
At which point I think the `gEdkiiDeviceSecurityProtocolGuid` should
work in PciBus [3]. Except the problem is that the PCIe bus is already
probed as `DeviceSecurityPolicyStub` consumes
`gEdkiiDeviceIdentifierTypePciGuid`. So I get stuck in a circular
loop.
Does anyone know how I can re-probe the `PciBusDxe` or somehow avoid
the circular dependency?
Or asking another way, is there a way to call the
`AuthenticatePciDevice()` [4] function after probing a PCIe device and
determining that the PCIe device supports DOE and SPDM? I don't see
any users of `gEfiDevicePathProtocolGuid` in upstream EDK2.
The gEfiDevicePathProtocolGuid is just a distributed namespace that is created by a UEFI bus driver as it enumerates. The bus driver inherits the Device Path of the parent (does not care what it looks like) and appends a Device Path node for the handle the bus driver is creating to represent the device. So it is basically just the name of the device. It came about since we needed to be able to make NVRAM Variables that pointed at hardware devices, so the hardware devices needed names that identified the devices even if the system got reconfigured.
So for example when the PCI Bus driver enumerates PCI devices it will create child handles and add a PCI Device Path [1] node. This node contains the PCI Dev and Func. It does not contain the bus as that could change based on a configuration change. The PCI bus driver will start enumerating at the root (some device path that represents the chipset) and then you enumerate the 1st level (bus 0) devices, if that device is a PCI to PCI bridge then it will have children with its own set of devices and functions. So you can recurse down, and if some one inserts a card and you reset the system the route is the same, but the assigned bus numbers change. For PCI there is not much reason to consume the gEfiDevicePathProtocolGuid as the EFI_PCI_IO_PROTOCOL [2], that the bus driver will install on the same handle as the Device Path has all the info contained in the Device Path, and much more.
1: 2: https://github.com/tianocore/edk2-staging/blob/DeviceSecurity/DeviceSecurityTestPkg/SpdmDeviceSecurityDxe/SpdmDeviceSecurityDxe.inf#L56
https://github.com/tianocore/edk2-staging/blob/DeviceSecurity/DeviceSecurityTestPkg/Test/DeviceSecurityPolicyStub/DeviceSecurityPolicyStub.inf#L36
3: https://github.com/tianocore/edk2-staging/blob/DeviceSecurity/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c#L299
4: https://github.com/tianocore/edk2-staging/blob/DeviceSecurity/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c#L2085
5: https://github.com/tianocore/edk2/pull/5715
PS: This is the second mail, the first didn't make it to the list
Alistair,
If you are not subscribed to the mailing list you mail gets stuck in a manual moderation bucket. So when it looks like the mail did not make it, you are just in with the people trying to sell lights for chickens, and all the people from around the world trying to sell mailing lists of people who attended random conferences we have never go to?
Thanks,
Andrew Fish