On Sun, Jul 14, 2024 at 10:42:41AM +0200, Lukas Wunner wrote: > It's probably too early to decide which actions to take if a device fails > authentication, whether to offer a variety of actions (only prevent driver > binding) or just stick to the harshest one (firewall off the device), > when to perform those actions and which knobs to offer to users for > controlling policy and overriding actions. We may need more real-world > experience before we can make those decisions and we may need to ask > security folks such as Kees Cook and Jann Horn for their perspective. I don't know PCI internals well enough to have any actionable opinion on many of the aspects of this thread, but I can try to give my perspective on the mitigation behavior at least. My main observation is that the CC threat model of "we can't trust what is attached to the bus" is an extremely high bar, and is not the common threat model for most deployments. As such, it seems like any associated behaviors need to defer to common deployments. It may just be as simple as making it a Kconfig option. That said, the best practice for such specialized behaviors is actually best put behind a static branch so that distros can able a given feature without making it on by default. (e.g. see the randomize_kstack_offset boot param[1].) Given the "module or builtin" question, I would expect this will end up being strictly a Kconfig, though. Anyway, following the threat model, it doesn't seem like half measures make any sense. If the threat model is "we cannot trust bus members" and authentication is being used to establish trust, then anything else must be explicitly excluded. If this can only be done via the described firewalling, then that really does seem to be the right choice. Now given what a high bar it is to not trust the bus, there are a lot of attack methodologies that likely need to be examined. For example, the bus has a different lifetime than the kernel, so it may be possible that members are attacking each other/the CPU/DMA etc, before Linux has even started running. If that can't be mitigated, then it doesn't matter what Linux is doing. This is why I've kind of tried to stay out of CC discussions: the threat models can be extremely hard to wrangle, and much of it depends on hardware design. :) I have enough to worry about just trying to protect the kernel from userspace. ;) -Kees [1] https://docs.kernel.org/admin-guide/kernel-parameters.html?highlight=randomize_kstack_offset -- Kees Cook
