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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Mar 23, 2026 at 07:18:17PM -0700, Dan Williams wrote:
> 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).

I feel like starting with trust=0 is much cleaner than using
autoprobe. Especially since it would be nice that when you do
ultimately set trust!=0 then you do want the kernel to do the normal
autoprobe flow.

Double so because I would like the iommu drivers to respond to trust 0
by fully blocking the device 100% of the time without holes, so to
make that work I would like to see the struct device report trust 0
the moment the iommu framework attaches the iommu.

How you decide the starting trust value for device during system boot
is definately something we need to discuss properly..

I liked your idea of using built in driver match, so if there is a
simple command line paramater that says 'only built in is trusted'
then we'd default all devices to untrusted and during device probe
check if any built in driver is matching and auto-set trust to X based
on the commandline parameter.

With the idea that only devices required to get to the initrd are
built in. Then the initrd userspace has the policy to bring more
devices into trusted!=0 to get to the root file system, then the
rootfs has more policy for further devices, and so on.

Probably this would ultimately escalate into annotations in the
modinfo about default policies for various drivers.

A kernel default policy of trusting everything without a "trust ops"
(see below) may also be quite reasonable, however boot ordering the
trust ops might be really tricky...

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

Maybe, but I was thinking the transition through run/locked would be
done through TSM uAPIs too. trust setting in the kernel just confirms
the device is in the right state.

But I haven't thought of a reason why the final switch to RUN couldn't
happen like this either.

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

Yes

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

Which is also why it would be nice to be consistent and rely on
trust=0 to isolate the device in all cases, not a mixture of
autoprobe.

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

I think if you want something like this then it is better to target
the root - remove the ability for concurrent userspace to wrongly
operate the TSM entirely. Ie use a cdev, make it so going to LOCKED
isolates access to only this cdev fd and require only this cdev fd to
go to RUN. Then these kinds of bugs don't exist.

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

Yes, I don't know anything about thunderbolt, but this seems
reasonable. You could also do as you suggested for TDISP that trust!=0
auto-authorizes.

Basically the 'trust' generic framework sits on top of some "trust
ops" that will be provided by the security module that is affiliated
with the struct device (ie thunderbolt, TSM TDISP, TSM Link IDE, etc,
etc)

Then it becomes a general synchronization point where on one side the
"tust ops" can ack that the level is acceptable and consistent with
the system when on the other side generic compoments like IOMMU,
driver binding, etc can respond to it and change their behavior.

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

I probably wouldn't use an int for the uAPI, but yes picking the
initial levels is important. As above since this is a clearing point
between two different worlds it needs to be defined in some way both
sides can understand what it means for them.

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

This seems reasonable to me, the 3/4 distinction is not meaningful for
the iommu&dev side, but it does provide a good check point for the
"trust ops". If userspace ack's that it expects physical security and
the kernel says it isn't physically secure (or becomes insecure later)
then it should fail.

> 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'm not sure that the SPDM driver even provides a "trust ops" right? I
would guess that 0/1/2 are simply built in always available if trust ops are
NULL and 3/4 require positive reply from the ops to accept it.

So #3 needs a "trust ops" linked to enabling link IDE.. If this is
done in-kernel the link IDE module is providing the trust ops and just
using SPDM as a library to establish the link IDE keys?

Jason