On Tue, Jul 09, 2024 at 11:10:57AM -0700, Dan Williams wrote:
> Lukas Wunner wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -121,6 +121,19 @@ config XEN_PCIDEV_FRONTEND
> > config PCI_ATS
> > bool
> >
> > +config PCI_CMA
> > + bool "Component Measurement and Authentication (CMA-SPDM)"
>
> What is driving the requirement for CMA to be built-in?
There is no way to auto-load modules needed for certain PCI features.
We'd have to call request_module() on PCI bus enumeration when
encountering devices with specific PCI features. But what do we do
if module loading fails? The PCI bus is enumerated in a subsys_initcall,
when neither the root filesystem has been mounted nor run_init_process()
has been called. So any PCI core modules would have to be in the initrd.
What if they aren't? Kernel panic? That question seems particularly
pertinent for a security feature like CMA.
So we've made PCI core features non-modular by default.
In seven cases we even switched from tristate to bool because building
as modules turned out not to be working properly:
82280f7af729 ("PCI: shpchp: Convert SHPC to be builtin only")
a4959d8c1eaa ("PCI: Remove DPC tristate module option")
774104399459 ("PCI: Convert ioapic to be builtin only, not modular")
67f43f38eeb3 ("s390/pci/hotplug: convert to be builtin only")
c10cc483bf3f ("PCI: pciehp: Convert pciehp to be builtin only, not modular")
7cd29f4b22be ("PCI: hotplug: Convert to be builtin only, not modular")
6037a803b05e ("PCI: acpiphp: Convert acpiphp to be builtin only, not modular")
There has not been a single case where we switched from bool to tristate,
with the exception of PCI_IOAPIC with commit b95a7bd70046, but that was
subsequently reverted back to bool with the above-listed 774104399459.
> All of the use cases I know about to date are built around userspace
> policy auditing devices after the fact.
I think we should also support use cases where user space sets a policy
(e.g. not to bind devices to a driver unless they authenticate) and lets
the kernel do the rest (i.e. autonomously authenticate devices based on
a set of trusted root certificates). User space does not *have* to be
the one auditing each device on a case-by-case basis, although I do see
the usefulness of such scenarios and am open to supporting them. In fact
this v2 takes a step in that direction by exposing signatures received
from the device to user space and doing so even if the kernel cannot
validate the device's certificate chains as well-formed and trusted.
In other words, I'm trying to support both: Fully autonomous in-kernel
authentication of certificates, but also allowing user space to make a
decision if it wants to. It's simply not clear to me at the moment
what the use cases will be. I can very well imagine that, say,
ChromeBooks will want to authenticate Thunderbolt-attached PCI devices
based on a keyring of trusted vendor certificates. The fully autonomous
in-kernel authentication caters to such a use case. I don't want to
preclude such use cases just because Confidential Computing in the
cloud happens to be the buzzword du jour.
Thanks,
Lukas
