Re: [PATCH 10/17] driver core: Expose device trust authorization through sysfs

[Robin Murphy <robin.murphy@arm.com>]

On 2026-11-05 2:43 pm, Andrew Lunn wrote:
>> Yup, and that's true even in the PCI TDISP case - there's a major amount of
>> "communication" and "configuration" involved in that. The principle which
>> should (hopefully) generalise is that a bus/host controller driver can
>> always interrogate its child device to perform whatever attestation and
>> general configuration is appropriate, but we won't hand off any _control_ of
>> that device to a specific device driver (nor enable potentially-impactful
>> bus-level features like DMA, interrupts, etc. if relevant) without the
>> requisite agreement between the bus code and the user.
> 
> Maybe it would be good to list subsystems which the bus driver can
> use, and cannot use.
> 
> You list interrupts as potentially being dangerous.

Nope, "impactful" - as in "things the hardware may do by itself that 
could impact the rest of the system". If it has wired interrupts, it may 
assert them at will as an attempt at some mild DoS or to try to hit some 
kind of known timing condition; if it has MSIs then it can effectively 
attempt to write at least one arbitrary word of data to an arbitrary 
address.

If the bus does happen to provide some way to physically prevent any 
such device-initiated behaviour from propagating until we OK it, then 
that's a nice thing to be able to include in our trust model.
> What about reset
> controllers, GPIOs, regulators? At least in the embedded world, the
> bus driver might need to enable power, set a clock ticking, and take
> the device out of reset via a GPIO, before the device pops into
> existence and will enumerate on the bus.

External resources that a device only _consumes_ should not need to 
factor into the trust of that device itself. If you want to worry from 
the PoV of the device whether _it_ trusts those external providers, that 
would be a whole other can of worms that I for one will run screaming 
from as fast as possible :)

Thanks,
Robin.

> I don't see why interrupts are dangerous, which makes it hard for me
> to determine if GPIOs and clocks, and regulators are also dangerous?
> 
>     Andrew