Access controllers: differentiate between access checks and grants?

Access controllers: differentiate between access checks and grants?

[Ahmad Fatoum]

Hi,

Quoting access-controllers.yaml:

  Access controllers are typically used to set/read the permissions of a
  hardware block and grant access to it.

I am afraid that having the exact same binding for both granting and
checking accesses complicates matters:

  1) Harder to reason about device trees: Does this property actually
     modify hardware state or not?

  2) More difficult migration: If access granting is added initially to
     Linux, but later moved into the secure world. How to reflect in
     the DT that the access controller has become read-only and that the
     driver should not attempt writes?

My suggestion would be adding an `access-checks-only;` or similar
property for access controllers that are read-only.

By setting this property for simple devices like efuses with feature
gates, we address 1) above.

2) is addressed by adding this property to Linux device tree (e.g. via
bootloader fixup) when secure firmware starts to handle a bus controller
itself.

An example where 2) would be relevant is the recent addition to
linux-next of the AIPSTZ[1] bridge for i.MX8MP. The power-on reset
defaults for the bridge preclude the DSP from accessing peripherals in
the bridge and they are lost when shutting down the relevant power
domain, so the driver takes care to apply a permissive access list on
probe and resume.

If we were to move this security setting into the secure world for
actual security benefit and made the controller read-only for normal
world, we will need a way to tell the Linux driver to avoid writing to
the peripheral.

access-checks-only could be that way.

Thoughts?

[1]:
https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/

Thanks,
Ahmad



-- 
Pengutronix e.K.                       |                             |
Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |

Re: Access controllers: differentiate between access checks and grants?

[Oleksii Moisieiev]

Hi Ahmad,

On 04/07/2025 12:08, Ahmad Fatoum wrote:
> [You don't often get email from a.fatoum@pengutronix.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi,
>
> Quoting access-controllers.yaml:
>
>    Access controllers are typically used to set/read the permissions of a
>    hardware block and grant access to it.
>
> I am afraid that having the exact same binding for both granting and
> checking accesses complicates matters:
>
>    1) Harder to reason about device trees: Does this property actually
>       modify hardware state or not?
 From my standpoint driver should decide this. The main purpose of the
device-tree is to provide information, not runtime data.
>    2) More difficult migration: If access granting is added initially to
>       Linux, but later moved into the secure world. How to reflect in
>       the DT that the access controller has become read-only and that the
>       driver should not attempt writes?
This sounds to me more as runtime configuration. I mean that in this
case we should handle 2 device-trees:
- configuration where HW didn't migrate to the Secure World
- configuration where read-only access is needed.
> My suggestion would be adding an `access-checks-only;` or similar
> property for access controllers that are read-only.
>
> By setting this property for simple devices like efuses with feature
> gates, we address 1) above.
>
> 2) is addressed by adding this property to Linux device tree (e.g. via
> bootloader fixup) when secure firmware starts to handle a bus controller
> itself.
>
> An example where 2) would be relevant is the recent addition to
> linux-next of the AIPSTZ[1] bridge for i.MX8MP. The power-on reset
> defaults for the bridge preclude the DSP from accessing peripherals in
> the bridge and they are lost when shutting down the relevant power
> domain, so the driver takes care to apply a permissive access list on
> probe and resume.
>
> If we were to move this security setting into the secure world for
> actual security benefit and made the controller read-only for normal
> world, we will need a way to tell the Linux driver to avoid writing to
> the peripheral.
>
> access-checks-only could be that way.
>
I've taken this example from [1]:
           access-controllers = <&aips5
                 IMX8MP_AIPSTZ_HIFI4
                 IMX8MP_AIPSTZ_MASTER
                 (IMX8MP_AIPSTZ_MPL | IMX8MP_AIPSTZ_MTW | IMX8MP_AIPSTZ_MTR)
             >;
What if just define some *_RO flag and add it for example with u-boot?
> Thoughts?
>
> [1]:
> https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/
>
> Thanks,
> Ahmad
>
>
>
> --
> Pengutronix e.K.                       |                             |
> Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |
>

Re: Access controllers: differentiate between access checks and grants?

[Ahmad Fatoum]

Hi Oleksii,

On 7/4/25 12:07, Oleksii Moisieiev wrote:
>> Quoting access-controllers.yaml:
>>
>>    Access controllers are typically used to set/read the permissions of a
>>    hardware block and grant access to it.
>>
>> I am afraid that having the exact same binding for both granting and
>> checking accesses complicates matters:
>>
>>    1) Harder to reason about device trees: Does this property actually
>>       modify hardware state or not?
>  From my standpoint driver should decide this. The main purpose of the
> device-tree is to provide information, not runtime data.

It's an aspect of the hardware if a device is accessible or not.
We have status and secure-status for example for devices strictly
partitioned for either normal or secure world.
There is also prior art for restricting usage of nodes, e.g.
protect-exec for SRAM or read-only for NVMEM.

So this is not misaligned with existing practice.

>>    2) More difficult migration: If access granting is added initially to
>>       Linux, but later moved into the secure world. How to reflect in
>>       the DT that the access controller has become read-only and that the
>>       driver should not attempt writes?
> This sounds to me more as runtime configuration. I mean that in this
> case we should handle 2 device-trees:
> - configuration where HW didn't migrate to the Secure World
> - configuration where read-only access is needed.

A migrated device tree might still want to describe the access
controller, e.g. so the probe of devices known to be off limits can be
skipped. Then we are back at square one of defining a binding on how to
differentiate between an access controller that does modification and
one that only does access checks.

>> My suggestion would be adding an `access-checks-only;` or similar
>> property for access controllers that are read-only.
>>

>> access-checks-only could be that way.
>>
> I've taken this example from [1]:
>            access-controllers = <&aips5
>                  IMX8MP_AIPSTZ_HIFI4
>                  IMX8MP_AIPSTZ_MASTER
>                  (IMX8MP_AIPSTZ_MPL | IMX8MP_AIPSTZ_MTW | IMX8MP_AIPSTZ_MTR)
>              >;
> What if just define some *_RO flag and add it for example with u-boot?
>> Thoughts?

As extra cell or as value that's OR'd into the last cell with the flags?
An extra cell would be an option, but I rather think it's a property
of the controller if it's read-only or not and not of the consumers?

Thanks,
Ahmad

>>
>> [1]:
>> https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/
>>
>> Thanks,
>> Ahmad
>>
>>
>>
>> --
>> Pengutronix e.K.                       |                             |
>> Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
>> 31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |
>>

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: Access controllers: differentiate between access checks and grants?

[Gatien CHEVALLIER]

Hello,

On 7/4/25 12:41, Ahmad Fatoum wrote:
> Hi Oleksii,
> 
> On 7/4/25 12:07, Oleksii Moisieiev wrote:
>>> Quoting access-controllers.yaml:
>>>
>>>     Access controllers are typically used to set/read the permissions of a
>>>     hardware block and grant access to it.
>>>

To be honest, I would like to separate the "set" permissions aspect from
this property before it's used in too many context because it makes it
impossible to distinguish whether we use this property for setting a
controller configuration in a secure context e.g: TEE at boot and only
granting access to a peripheral.
Granting access may include acquisition of some resources but these
resources should not be the controller configuration itself. Here's an
attempt [1] that did not receive feedback yet to add a dedicated
pattern property for setting configurations.

I'd be grateful if you guys can provide me feedback on this.

>>> I am afraid that having the exact same binding for both granting and
>>> checking accesses complicates matters:
>>>
>>>     1) Harder to reason about device trees: Does this property actually
>>>        modify hardware state or not?
>>   From my standpoint driver should decide this. The main purpose of the
>> device-tree is to provide information, not runtime data.
> 
> It's an aspect of the hardware if a device is accessible or not.
> We have status and secure-status for example for devices strictly
> partitioned for either normal or secure world.
> There is also prior art for restricting usage of nodes, e.g.
> protect-exec for SRAM or read-only for NVMEM.
> 
> So this is not misaligned with existing practice.
> 
>>>     2) More difficult migration: If access granting is added initially to
>>>        Linux, but later moved into the secure world. How to reflect in
>>>        the DT that the access controller has become read-only and that the
>>>        driver should not attempt writes?
>> This sounds to me more as runtime configuration. I mean that in this
>> case we should handle 2 device-trees:
>> - configuration where HW didn't migrate to the Secure World
>> - configuration where read-only access is needed.
> 
> A migrated device tree might still want to describe the access
> controller, e.g. so the probe of devices known to be off limits can be
> skipped. Then we are back at square one of defining a binding on how to
> differentiate between an access controller that does modification and
> one that only does access checks.
> 
>>> My suggestion would be adding an `access-checks-only;` or similar
>>> property for access controllers that are read-only.
>>>
> 
>>> access-checks-only could be that way.
>>>
>> I've taken this example from [1]:
>>             access-controllers = <&aips5
>>                   IMX8MP_AIPSTZ_HIFI4
>>                   IMX8MP_AIPSTZ_MASTER
>>                   (IMX8MP_AIPSTZ_MPL | IMX8MP_AIPSTZ_MTW | IMX8MP_AIPSTZ_MTR)
>>               >;
>> What if just define some *_RO flag and add it for example with u-boot?
>>> Thoughts?
> 
> As extra cell or as value that's OR'd into the last cell with the flags?
> An extra cell would be an option, but I rather think it's a property
> of the controller if it's read-only or not and not of the consumers?
> 

IMO, adding an extra cell (simple boolean value) dedicated to this
purpose for your case is a good idea. The bindings states that it's
used to grant access to a hardware block. Whether the "granting"
process is just checking or having to acquire some resources is up
to each controller. Does that seem fair to you? It should address
both 1) and 2).

> Thanks,
> Ahmad
>

>>>
>>> [1]:
>>> https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/
>>>
>>> Thanks,
>>> Ahmad
>>>
>>>
>>>
>>> --
>>> Pengutronix e.K.                       |                             |
>>> Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
>>> 31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
>>> Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |
>>>
> 

[1]:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250523-access-controllers-conf-v3-1-4382e69819cf@foss.st.com/

(I'm sorry I can't find the kernel lore link even using filters on the
URL)

Best regards,
Gatien

Re: Access controllers: differentiate between access checks and grants?

[Oleksii Moisieiev]

On 04/07/2025 13:41, Ahmad Fatoum wrote:
> [You don't often get email from a.fatoum@pengutronix.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Oleksii,
>
> On 7/4/25 12:07, Oleksii Moisieiev wrote:
>>> Quoting access-controllers.yaml:
>>>
>>>     Access controllers are typically used to set/read the permissions of a
>>>     hardware block and grant access to it.
>>>
>>> I am afraid that having the exact same binding for both granting and
>>> checking accesses complicates matters:
>>>
>>>     1) Harder to reason about device trees: Does this property actually
>>>        modify hardware state or not?
>>   From my standpoint driver should decide this. The main purpose of the
>> device-tree is to provide information, not runtime data.
> It's an aspect of the hardware if a device is accessible or not.
> We have status and secure-status for example for devices strictly
> partitioned for either normal or secure world.
> There is also prior art for restricting usage of nodes, e.g.
> protect-exec for SRAM or read-only for NVMEM.
>
> So this is not misaligned with existing practice.
>
>>>     2) More difficult migration: If access granting is added initially to
>>>        Linux, but later moved into the secure world. How to reflect in
>>>        the DT that the access controller has become read-only and that the
>>>        driver should not attempt writes?
>> This sounds to me more as runtime configuration. I mean that in this
>> case we should handle 2 device-trees:
>> - configuration where HW didn't migrate to the Secure World
>> - configuration where read-only access is needed.
> A migrated device tree might still want to describe the access
> controller, e.g. so the probe of devices known to be off limits can be
> skipped. Then we are back at square one of defining a binding on how to
> differentiate between an access controller that does modification and
> one that only does access checks.
>
>>> My suggestion would be adding an `access-checks-only;` or similar
>>> property for access controllers that are read-only.
>>>
>>> access-checks-only could be that way.
>>>
>> I've taken this example from [1]:
>>             access-controllers = <&aips5
>>                   IMX8MP_AIPSTZ_HIFI4
>>                   IMX8MP_AIPSTZ_MASTER
>>                   (IMX8MP_AIPSTZ_MPL | IMX8MP_AIPSTZ_MTW | IMX8MP_AIPSTZ_MTR)
>>               >;
>> What if just define some *_RO flag and add it for example with u-boot?
>>> Thoughts?
> As extra cell or as value that's OR'd into the last cell with the flags?
> An extra cell would be an option, but I rather think it's a property
> of the controller if it's read-only or not and not of the consumers?
If this should be applied to the controller itself then your approach is
an option. For our use-case we are using only
"set" option.
> Thanks,
> Ahmad
>
>>> [1]:
>>> https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/
>>>
>>> Thanks,
>>> Ahmad
>>>
>>>
>>>
>>> --
>>> Pengutronix e.K.                       |                             |
>>> Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
>>> 31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
>>> Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |
>>>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>