Kees Cook wrote: > 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. This is where the discussion jumps off into details and needs more precision. Mere authentication, PCI CMA, does not establish trust in the device. Authentication only tells you that the device provided a certificate that matched a value read from config-space. That device's config-space can be spoofed and / or the MMIO registers that the driver thinks it is talking to can be spoofed. So establishing trust in the *bus* requires PCI TDISP. > 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. Right, PCI TDISP considers this, PCI CMA does not. > 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. ;) Yes, I am trying to find a path that allows for incrementally enabling these security technologies while not overselling the value, and not completely invalidating the Linux device driver model as "step1". Even with PCI TDISP, and the end-to-end trust that the PCI interface is the one you expect, a lot can happen once traffic crosses the bus-to-device interface.
