* Lukas Wunner (lukas@xxxxxxxxx) wrote: > [cc += Jonathan Cameron, linux-pci] > > On Wed, Jan 25, 2023 at 02:57:40PM +0000, Dr. David Alan Gilbert wrote: > > Greg Kroah-Hartman (gregkh@xxxxxxxxxxxxxxxxxxx) wrote: > > > Great, so why not have hardware attestation also for your devices you > > > wish to talk to? Why not use that as well? Then you don't have to > > > worry about anything in the guest. > > > > There were some talks at Plumbers where PCIe is working on adding that; > > it's not there yet though. I think that's PCIe 'Integrity and Data > > Encryption' (IDE - sigh), and PCIe 'Security Prtocol and Data Model' - > > SPDM. I don't know much of the detail of those, just that they're far > > enough off that people aren't depending on them yet. > > CMA/SPDM (PCIe r6.0 sec 6.31) is in active development on this branch: > > https://github.com/l1k/linux/commits/doe Thanks for the pointer - I'll go and hunt down that spec. > It will allow for authentication of PCIe devices. Goal is to submit > this quarter (Q1). Afterwards we'll look into retrieving measurements > via CMA/SPDM and bringing up IDE encryption. > > It's a kernel-native implementation which uses the existing crypto and > keys infrastructure and is wired into the appropriate places in the > PCI core to authenticate devices on enumeration and reauthenticate > when CMA/SPDM state is lost (after resume from D3cold, after a > Secondary Bus Reset and after a DPC-induced Hot Reset). > > The device authentication service afforded here is generic. > It is up to users and vendors to decide how to employ it, > be it for "confidential computing" or something else. As Samuel asks about who is doing the challenge; but I guess there are also things like what happens when the host controls intermediate switches and BAR access and when only VFs are passed to guests. > Trusted root certificates to validate device certificates can be > installed into a kernel keyring using the familiar keyctl(1) utility, > but platform-specific roots of trust (such as a HSM) could be > supported as well. > > I would like to stress that this particular effort is a collaboration > of multiple vendors. It is decidedly not a single vendor trying to > shoehorn something into upstream, so the criticism that has been > leveled upthread against other things does not apply here. > > The Plumbers BoF you're referring to was co-authored by Jonathan Cameron > and me and its purpose was precisely to have an open discussion and > align on an approach that works for everyone: > > https://lpc.events/event/16/contributions/1304/ > > > > a) there's no good way to authenticate a PCI device yet > > - any nasty device can claim to have a given PCI ID. > > CMA/SPDM prescribes that the Subject Alternative Name of the device > certificate contains the Vendor ID, Device ID, Subsystem Vendor ID, > Subsystem ID, Class Code, Revision and Serial Number (PCIe r6.0 > sec 6.31.3). > > Thus a forged Device ID in the Configuration Space Header will result > in authentication failure. Good! It'll be nice when people figure out the CoCo integration for that; I'm still guessing it's a little way off until we get hardware for that. Dave > Thanks, > > Lukas > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
