Lukas Wunner wrote:
> 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.
TSM is taking the approach of dynamically adjusting the visibility of
TSM attributes when the platform TSM driver registers with the PCI core.
It is forced to do this because a TSM controller may itself be a PCI
that needs a driver to load before the PCI core attributes are usable.
For native functionality, yes, it would indeed take synthetic device to
play the same role.
> 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.
Non-authenticated operation is the status quo. CMA is a building block
to other security features. Nothing currently cares about CMA being
established before a driver loads and it is not clear that now is the
time to for the kernel to paint itself into a corner to make that
guarantee.
> 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.
That's good history that I was not aware, thanks for that.
However, most of those seem to be knock-on effects of:
https://lore.kernel.org/all/20121207062454.11051.12739.stgit@amt.stowe/
...where init order constraints between ACPI and PCI functionality led
to modules not being viable. The DPC one does not fit that model, but
DPC is small enough and entangled with AER to not really justify it
being a standalone module.
> > 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.
Userspace validation of authentication and measurement is separate from
whether the functionality is built-in or not.
> 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 think you are conflating automatic authentication and built-in
functionality. There are counter examples of security features like
encrypted root filesystems built on top of module drivers.
What I am trying to avoid is CMA setting unnecessary expectations that
can not be duplicated by TSM like "all authentication capable PCI
devices will be authenticated prior to driver attach".
Now, might there be a reason for native TSM and CMA to diverge on this
policy / capability in the future, maybe? It certainly is not here
today.
> preclude such use cases just because Confidential Computing in the
> cloud happens to be the buzzword du jour.
As if CMA is somehow not part of the "buzzword du jour" of Confidential
Computing?
