Re: [PATCH v2 03/19] device core: Introduce confidential device acceptance

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Mar 13, 2026 at 06:32:27PM -0700, Dan Williams wrote:

> The problem is that for all the buses that do not currently have a
> "device authorization" concept only userspace can decide that a device
> should skip bind by default. For that, I propose module autoprobe policy
> [1]. Not yet convinced the kernel needs its own per-device "no bind"
> policy.

I think it is just part of the broader definition of the level that
extends into the iommu and so on. It makes sense to have this kind of
no-binding security level, IMHO.

> > The DMA API just wants a flag in the struct device that says if the
> > device can access encrypted memory or only decrypted.
> 
> You mean separate "trusted to access private" and "currently enabled to
> access private" properties? I am trying to think of a situation where
> "dev->trust >= 3" and a flag saying "disable bouncing for encrypted
> memory" would ever disagree.

I'm steering the trust level toward more of an acceptance criteria.
If the trust level is you have access to private memory but the device
can't actually do that then fail the trust level change.

Same for the reverse, if the trust level says no private memory and the
device is T=1 then fail the trust level change.

> That bit though has lock-to-run consistency expectations. So if the
> kernel does not yet fully trust the device by time the relying party is
> satisfied, and the uAPI to transition the device into the TCB (level 3)
> is driver-core generic it raises TOCTOU issues in my mind. The
> driver-core would need to ask the bus "user now trusts this device, do
> you?".

Huh? No, there is no concept of trust in the kernel. The userspace
setting level 3 is "I now ack that this device is trusted", there is
no further trust cross check. If TSM side says it is in RUN/T=1 then
we are done.

If we fall out of RUN then the level auto-resets back to 0 and
userspace has to go around and fix it again. (ignoring driver RAS)

> Aneesh and I are currently debating on Discord whether the kernel needs
> to protect against guest userspace confusing itself. 

Userspace that controls acceptance must be part of the TCB or the
whole model is fully broken. If your guest userspace is so security
broken it can accept devices it doesn't mean to then just forget it.

> However, to Aneesh's point we could protect against that with a
> transactional uAPI like netlink that can express "trust if and only if
> the device has not been relocked before final accept" by passing a
> cookie obtained at lock to accept. That would be awkward to coordinate
> with driver-core generic uAPI for trust.

You could, but why make it so complicated? The whole LOCKED/RUN thing
is already supposed to deal with TOCTOU, doesn't it? The CSP cannot
trick a device to fall out of LOCKED an the re-enter LOCKED without
the VM knowing.

The VM attacking itself on something as security critical as device
accepance can't be in scope :\

> > This way nothing is coupled and the kernel can offer all kinds of
> > different uAPI for device verification. Userspaces picks the
> > appropriate one and acks it with the level change.
> 
> Thunderbolt already has authorized uAPI. I expect adding dev->trust
> support to thunderbolt is more related to ATS privilege and private
> memory privilege.

It brings it into the whole 'measure the device and then decide what
to do with it' framework. The trust level is still the generic ack
that the device is allowed the participate in the system with whatever
level of security.

Jason