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

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

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

I do agree that forcing trust=0 at the beginning of time is attractive
and theoretically clean. I am concerned about subsystems that are not
prepared for driver attach failures. For example, I would not expect to
need to set trust for auxiliary bus devices if the host device is
trusted.

However, the work to set module autoprobe policy is on the same order as
adding a module scoped trust policy.

So something like "modprobe $module trust=X" automatically tries to set
the device trust level on attach to any drivers in that module. That
could allow a semantic of "attach iff device is able to go to level 4".

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

Yes, escalate over time for subsystems to say "devices I create are
trusted, the responsibility to manage trust lies with clients of my
APIs".

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

Given the optionality in selecting a trust ops provider I think it gets
extra messy quickly. Let me see how far I can get with built-in auto
trust + module trust policy.

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

Right, the potential to see in-between states concerns me because TSM
uAPIs would have fully enabled the device to wreak havoc, meanwhile
dev->trust is still showing the device at some lower level of trust. So
I think trust modification needs to be synchronous with privileges
granted/revoked.

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

The netlink evidence proposal can handle this, it just needs a
'validate' command. 'Validate' records a device evidence generation
number. Require a stable generation number between entering LOCK and the
trust=4 event transitioning the device to RUN.

Yes, not as safe as fd-private LOCK-to-RUN, but I like semantic of
"modprobe $module trust=4" to say "transition to RUN and attach to all
validated devices".

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

Something like this, yes.

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

Yes, but an int for now saves the bikeshed of the level names till a bit
later.

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

Right. Even though the SPDM driver allows device evidence to be
collected there is no event like LOCK-to-RUN that expects validated
evidence as a precondition.

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

Yes, but note to date only Intel platforms allow for IDE establishment
without talking to the platform TSM.