On 3/3/23 07:22, Lukas Wunner wrote:
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.
Well, not sizeof(pci_dev) as much, it is more about DOE/SPDM code being
compiled into vmlinux - it is hard for me to imagine this running on my
laptop soon but distros dislike multiple kernel configs. Not a huge deal
but still.
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.
These guys all use custom configs (as was also suggested in that threat
thread - "Linux guest kernel threat model for Confidential Computing").
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?
The AMD CCP device (which represents PSP == a secure processor == TCB
for SEV VMs) is a PCI device and when we add TDISP/etc to the TCB, we
will need the host to speak to PSP to set this up. It does not matter
for host-only IDE support though.
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:
https://cdrdv2-public.intel.com/742542/software-enabling-for-tdx-tee-io-fixed.pdf
suggests that TDX is going to have to reimplement SPDM/IDE/TDISP again
so the common base here is DOE only, is not it?
And what is the value of TDISP without a device driver, how can the PCI
core decide if the device is alright to use? I am sure there is value
but my imagination fails me.
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.
While I am figuring this out, is it a bug? :)
https://github.com/l1k/linux/commit/c1b242d74d55d361934bdcff1bb4f881922b10ae#r102531215
Thanks,
Thanks,
Lukas
--
Alexey
