Re: [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration

[Kees Cook <kees@kernel.org>]

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