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

[Dan Williams <dan.j.williams@intel.com>]

Jason Gunthorpe wrote:
> 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.

Easy to include for completeness.

In a CC VM userspace can set "$module autoprobe=0" to get a control
point to set @trust to zero, but @trust otherwise defaults to 1. This
allows for userspace policy to generically distrust devices, but without
needing to build a new mechanism to specify which devices start life at
trust == 0 (i.e.  "device filter" proposal previously NAK'd).

> > > 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.

Ok, so the uapi for PCI/TDISP would be:

echo $tsm > $pdev/tsm/lock
<gather evidence, validate with relying party>
echo 3 > $pdev/trust

...where that @trust attribute is a generic device semantic, but in the
case of PCI device connected to a given TSM it invokes the TSM hypercall
to transition the device to the RUN state and the TSM local call to
unblock DMA to private memory.

So, userspace can generically understand what privileges come with which
trust levels, but the mechanism to get those privileges remains bus
specific.

> > 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.

Ok, so maybe I misunderstood your point. Per the above, if the trust
setting is what kicks the bus to finalize T=1 then it makes sense. If
that kick fails, the user's trust setting request fails.

What I expect is unwanted / surprising is device has already been
transitioned to T=1 state ahead of the trust setting, it is a
synchronous mechanism.

> 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)

Yes, at the moment that the bus detects that an event like SPDM session
loss, IDE link loss, TDISP ERROR state entry has occurred it can
downgrade trust and notify. That notification fits well with netlink
because all of those events are downstream of evidence validation.

> > 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.

Agree, it is a non-problem. If guest userspace confuses itself by racing
sysfs operations then the relying party should not trust that userspace.

> > 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?

Right, the threat vector is the guest accepting something it has had no
chance to validate. Guest userspace confusion is not that. Guest
userspace asking the device to be re-locked in a way that confuses an
ongoing evidence validation sequence in another thread is a "you get to
keep the pieces" event.

> 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 :\

The complication vs benefit tradeoff is indeed not mathing, but wanted
to do justice to Aneesh's proposal and the suitability of the sysfs
uapi.

> > > 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.

Some thought experiments to confirm alignment...

'Generic ack' is a synchronous mechanism for the bus to evaluate. So if
@trust appears for any device, and by consequence alongside @authorized
for a thunderbolt device, it should be the case that these operations
are equivalent:

# echo 1 > $dev/trust
# echo 1 > $dev/authorized

...and the result is cross-reflected for comptability:

# echo 1 > $dev/trust
# cat $dev/authorized
1

Consequently this:

# echo 2 > $dev/trust

...would be equivalent to authorizing the device and unblocking ATS (if
such a thing existed).

For bare metal PCI device security the TSM 'connection' needs to be
established in order to enable device evidence collection.

echo $tsm > $pdev/tsm/connect
<validate device evidence>
echo 2 > $pdev/trust

Now, I question whether 5 trust levels instead of 4. This would be to
explicitly only trust devices where the TSM has established physical
link encryption, or the TSM has asserted that the link is protected by
other means. So the trust levels are:

0 disconnected: bus does not attach drivers
1 limited: core code deploys hostile device mitigations like disable
           ATS, CC force shared memory bouncing.
2 DMA: full DMA access, driver responsible for protecting against
       adverarial devices.
3 Link: mitigations against physical integrity and snooping attacks
        deployed
4 TCB: full device interface validation via a protocol like TDISP,
       CC private memory access granted.

Where the native Rust library based SPDM driver only offers trust level
2, bare metal TSMs can support trust level 3, and the TSM interfaces in
CC VMs can support trust level 4. I could see squashing 2 and 3 and
making it a documentation problem to understand the capabilities of the
various TSM drivers.