From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>

The AIPSTZ bridge offers some security-related configurations which can
be used to restrict master access to certain peripherals on the bridge.

Normally, this could be done from a secure environment such as ATF before
Linux boots but the configuration of AIPSTZ5 is lost each time the power
domain is powered off and then powered on. Because of this, it has to be
configured each time the power domain is turned on and before any master
tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).

The child-parent relationship between the bridge and its peripherals
should guarantee that the bridge is configured before the AP attempts
to access the IPs.

Other masters should use the 'access-controllers' property to enforce
a dependency between their device and the bridge device (see the DSP,
for example).

At the moment, we only want to apply a default, more relaxed
configuration, which is why the number of access controller cells
is 0.

The initial version of the series can be found at [1]. The new version
should provide better management of the device dependencies.

[1]: https://lore.kernel.org/linux-arm-kernel/20241119130726.2761726-1-daniel.baluta@nxp.com/

---
Changes in v2:
* adress Frank Li's comments
* pick up some A-b/R-b's
* don't use "simple-bus" as the second compatible. As per Krzysztof's
comment, AIPSTZ is not a "simple-bus".
---

Laurentiu Mihalcea (5):
  dt-bindings: bus: add documentation for the IMX AIPSTZ bridge
  dt-bindings: dsp: fsl,dsp: document 'access-controllers' property
  bus: add driver for IMX AIPSTZ bridge
  arm64: dts: imx8mp: convert 'aips5' to 'aipstz5'
  arm64: dts: imx8mp: make 'dsp' node depend on 'aips5'

 .../bindings/bus/fsl,imx8mp-aipstz.yaml       | 86 +++++++++++++++++
 .../devicetree/bindings/dsp/fsl,dsp.yaml      |  3 +
 arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  9 +-
 drivers/bus/Kconfig                           |  6 ++
 drivers/bus/Makefile                          |  1 +
 drivers/bus/imx-aipstz.c                      | 92 +++++++++++++++++++
 6 files changed, 194 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
 create mode 100644 drivers/bus/imx-aipstz.c

-- 
2.34.1

Hi,

On 25-02-26, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> 
> The AIPSTZ bridge offers some security-related configurations which can
> be used to restrict master access to certain peripherals on the bridge.
> 
> Normally, this could be done from a secure environment such as ATF before
> Linux boots but the configuration of AIPSTZ5 is lost each time the power
> domain is powered off and then powered on. Because of this, it has to be
> configured each time the power domain is turned on and before any master
> tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).

My question still stands:

Setting these bits requires very often that the core is running at EL3
(e.g. secure-monitor) which is not the case for Linux. Can you please
provide more information how Linux can set these bits?

Regards,
  Marco

> The child-parent relationship between the bridge and its peripherals
> should guarantee that the bridge is configured before the AP attempts
> to access the IPs.
> 
> Other masters should use the 'access-controllers' property to enforce
> a dependency between their device and the bridge device (see the DSP,
> for example).
> 
> At the moment, we only want to apply a default, more relaxed
> configuration, which is why the number of access controller cells
> is 0.
> 
> The initial version of the series can be found at [1]. The new version
> should provide better management of the device dependencies.
> 
> [1]: https://lore.kernel.org/linux-arm-kernel/20241119130726.2761726-1-daniel.baluta@nxp.com/
> 
> ---
> Changes in v2:
> * adress Frank Li's comments
> * pick up some A-b/R-b's
> * don't use "simple-bus" as the second compatible. As per Krzysztof's
> comment, AIPSTZ is not a "simple-bus".
> ---
> 
> Laurentiu Mihalcea (5):
>   dt-bindings: bus: add documentation for the IMX AIPSTZ bridge
>   dt-bindings: dsp: fsl,dsp: document 'access-controllers' property
>   bus: add driver for IMX AIPSTZ bridge
>   arm64: dts: imx8mp: convert 'aips5' to 'aipstz5'
>   arm64: dts: imx8mp: make 'dsp' node depend on 'aips5'
> 
>  .../bindings/bus/fsl,imx8mp-aipstz.yaml       | 86 +++++++++++++++++
>  .../devicetree/bindings/dsp/fsl,dsp.yaml      |  3 +
>  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  9 +-
>  drivers/bus/Kconfig                           |  6 ++
>  drivers/bus/Makefile                          |  1 +
>  drivers/bus/imx-aipstz.c                      | 92 +++++++++++++++++++
>  6 files changed, 194 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
>  create mode 100644 drivers/bus/imx-aipstz.c
> 
> -- 
> 2.34.1
> 
> 
>

Hi Laurentiu,

On 25-02-26, Marco Felsch wrote:
> Hi,
> 
> On 25-02-26, Laurentiu Mihalcea wrote:
> > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > 
> > The AIPSTZ bridge offers some security-related configurations which can
> > be used to restrict master access to certain peripherals on the bridge.
> > 
> > Normally, this could be done from a secure environment such as ATF before
> > Linux boots but the configuration of AIPSTZ5 is lost each time the power
> > domain is powered off and then powered on. Because of this, it has to be
> > configured each time the power domain is turned on and before any master
> > tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).
> 
> My question still stands:
> 
> Setting these bits requires very often that the core is running at EL3
> (e.g. secure-monitor) which is not the case for Linux. Can you please
> provide more information how Linux can set these bits?

Sorry I didn't noticed your response:

https://lore.kernel.org/all/a62ab860-5e0e-4ebc-af1f-6fb7ac621e2b@gmail.com/

If EL1 is allowed to set the security access configuration of the IP
cores doesn't this mean that a backdoor can be opened? E.g. your
secure-boot system configures one I2C IP core to be accessible only from
secure-world S-EL1 (OP-TEE) and after the power-domain was power-cycled
it's accessible from EL1 again. This doesn't seem right. Why should a
user be able to limit the access permissions to an IP core to only be
accessible from secure-world if the IP core is accessible from
normal-world after the power-domain was power-cycled.

Regards,
  Marco

On 2/27/2025 1:28 PM, Marco Felsch wrote:
> Hi Laurentiu,
>
> On 25-02-26, Marco Felsch wrote:
>> Hi,
>>
>> On 25-02-26, Laurentiu Mihalcea wrote:
>>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>>
>>> The AIPSTZ bridge offers some security-related configurations which can
>>> be used to restrict master access to certain peripherals on the bridge.
>>>
>>> Normally, this could be done from a secure environment such as ATF before
>>> Linux boots but the configuration of AIPSTZ5 is lost each time the power
>>> domain is powered off and then powered on. Because of this, it has to be
>>> configured each time the power domain is turned on and before any master
>>> tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).
>> My question still stands:
>>
>> Setting these bits requires very often that the core is running at EL3
>> (e.g. secure-monitor) which is not the case for Linux. Can you please
>> provide more information how Linux can set these bits?
> Sorry I didn't noticed your response:
>
> https://lore.kernel.org/all/a62ab860-5e0e-4ebc-af1f-6fb7ac621e2b@gmail.com/
>
> If EL1 is allowed to set the security access configuration of the IP
> cores doesn't this mean that a backdoor can be opened? E.g. your
> secure-boot system configures one I2C IP core to be accessible only from
> secure-world S-EL1 (OP-TEE) and after the power-domain was power-cycled
> it's accessible from EL1 again. This doesn't seem right. Why should a
> user be able to limit the access permissions to an IP core to only be
> accessible from secure-world if the IP core is accessible from
> normal-world after the power-domain was power-cycled.
>
> Regards,
>   Marco

I'm no security expert so please feel free to correct me if I get something wrong.

This isn't about S/NS world. The bridge AC doesn't offer any configurations for
denying access to peripherals based on S/NS world. AFAIK that's the job of the CSU
(central security unit), which is a different IP.

Perhaps I shouldn't have used the term "trusted" as it might have ended up creating
more confusion? If so, please do let me know so I can maybe add a comment about
it in one of the commit messages. In this context, "master X is trusted for read/writes"
means "master X is allowed to perform read/write transactions".

Even if the bridge is configured to allow read/write transactions from a master
(i.e: master is marked as trusted for read/writes) that wouldn't be very helpful.
You'd still have to bypass the CSU configuration which as far as I understand is also
used by the bridge to deny access to peripherals (e.g: if transaction is secure+privileged
then forward to peripheral, otherwise abort it). See the "4.7.6.1 Security Block"
and "4.7.4  Access Protections" chapters from the IMX8MP RM.

Given all of this, I think the purpose of this IP's AC is to add some extra,
light, security features on top of the CSU.

On 25-03-05, Laurentiu Mihalcea wrote:
> 
> On 2/27/2025 1:28 PM, Marco Felsch wrote:
> > Hi Laurentiu,
> >
> > On 25-02-26, Marco Felsch wrote:
> >> Hi,
> >>
> >> On 25-02-26, Laurentiu Mihalcea wrote:
> >>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >>>
> >>> The AIPSTZ bridge offers some security-related configurations which can
> >>> be used to restrict master access to certain peripherals on the bridge.
> >>>
> >>> Normally, this could be done from a secure environment such as ATF before
> >>> Linux boots but the configuration of AIPSTZ5 is lost each time the power
> >>> domain is powered off and then powered on. Because of this, it has to be
> >>> configured each time the power domain is turned on and before any master
> >>> tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).
> >> My question still stands:
> >>
> >> Setting these bits requires very often that the core is running at EL3
> >> (e.g. secure-monitor) which is not the case for Linux. Can you please
> >> provide more information how Linux can set these bits?
> > Sorry I didn't noticed your response:
> >
> > https://lore.kernel.org/all/a62ab860-5e0e-4ebc-af1f-6fb7ac621e2b@gmail.com/
> >
> > If EL1 is allowed to set the security access configuration of the IP
> > cores doesn't this mean that a backdoor can be opened? E.g. your
> > secure-boot system configures one I2C IP core to be accessible only from
> > secure-world S-EL1 (OP-TEE) and after the power-domain was power-cycled
> > it's accessible from EL1 again. This doesn't seem right. Why should a
> > user be able to limit the access permissions to an IP core to only be
> > accessible from secure-world if the IP core is accessible from
> > normal-world after the power-domain was power-cycled.
> >
> > Regards,
> >   Marco
> 
> I'm no security expert so please feel free to correct me if I get
> something wrong.
> 
> This isn't about S/NS world. The bridge AC doesn't offer any
> configurations for denying access to peripherals based on S/NS world.

It does, please see the AIPSTZ_OPACR register definition. The imx-atf of
sets OPACR registers to 0 (of course), which means that the S/NS is not
checked _but_ it can be configured.

Also please see chapter 4.7.6.1 Security Block:

The AIPSTZ contains a security block that is connected to each
off-platform peripheral. This block filters accesses based on
write/read, non-secure, and supervisor signals.

> AFAIK that's the job of the CSU (central security unit), which is a
> different IP.

Please see above.

> Perhaps I shouldn't have used the term "trusted" as it might have
> ended up creating more confusion? If so, please do let me know so I
> can maybe add a comment about it in one of the commit messages. In
> this context, "master X is trusted for read/writes" means "master X is
> allowed to perform read/write transactions".

No you didn't confused me but you triggered my interest :) and I started
to check the (S)TRM.

> Even if the bridge is configured to allow read/write transactions from
> a master (i.e: master is marked as trusted for read/writes) that
> wouldn't be very helpful.

We're talking about the IP access permissions, right. If the
"secure-I2C" is accessible from NS world this would make a difference of
course.

> You'd still have to bypass the CSU configuration which as far as I
> understand is also used by the bridge to deny access to peripherals
> (e.g: if transaction is secure+privileged then forward to peripheral,
> otherwise abort it). See the "4.7.6.1 Security Block" and "4.7.4 
> Access Protections" chapters from the IMX8MP RM.

I have read this too, also that the AIPSTZ can force the mode into
user_mode regardless of the CSU settings, if I get this correct.

What I don't understand as of now is the interaction of the AIPSTZ and
the CSU. You can configure different bus-masters within the CSU to be
S/NS as well as the pheripherals. Now the part which I don't understand
right now: According the OPACx register description:

x0xx SP0 — This peripheral does not require supervisor privilege level
           for accesses.
x1xx SP1 — This peripheral requires supervisor privilege level for
           accesses. The master privilege level must indicate supervisor
	   via the hprot[1] access attribute, and the MPROTx[MPL] control
	   bit for the master must be set. If not, the access is
	   terminated with an error response and no peripheral access is
	   initiated on the IPS bus.

The peripheral can be configured via the AIPSTZ as well. So which IP
(CSU or AIPSTZ) override the other if the settings don't match, e.g. if
CSU says: "this I2C controller for secure-world" and the AIPSTZ says:
"this I2C is for non-secure-world".

> Given all of this, I think the purpose of this IP's AC is to add some
> extra, light, security features on top of the CSU.

Or to override the CSU settings like the MPROTOx values:

xxx0 MPL0 — Accesses from this master are forced to user-mode
           (ips_supervisor_access is forced to zero) regardless of the
	   hprot[1] access attribute.
xxx1 MPL1 — Accesses from this master are not forced to user-mode. The
            hprot[1] access attribute is used directly to determine
	    ips_supervisor_access.

Can you pleae elaborate a bit more how NXP designed the interaction
between both the AIPSTZ and the CSU?

Regards,
  Marco

On 3/7/2025 4:39 PM, Marco Felsch wrote:
> On 25-03-05, Laurentiu Mihalcea wrote:
>> On 2/27/2025 1:28 PM, Marco Felsch wrote:
>>> Hi Laurentiu,
>>>
>>> On 25-02-26, Marco Felsch wrote:
>>>> Hi,
>>>>
>>>> On 25-02-26, Laurentiu Mihalcea wrote:
>>>>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>>>>
>>>>> The AIPSTZ bridge offers some security-related configurations which can
>>>>> be used to restrict master access to certain peripherals on the bridge.
>>>>>
>>>>> Normally, this could be done from a secure environment such as ATF before
>>>>> Linux boots but the configuration of AIPSTZ5 is lost each time the power
>>>>> domain is powered off and then powered on. Because of this, it has to be
>>>>> configured each time the power domain is turned on and before any master
>>>>> tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).
>>>> My question still stands:
>>>>
>>>> Setting these bits requires very often that the core is running at EL3
>>>> (e.g. secure-monitor) which is not the case for Linux. Can you please
>>>> provide more information how Linux can set these bits?
>>> Sorry I didn't noticed your response:
>>>
>>> https://lore.kernel.org/all/a62ab860-5e0e-4ebc-af1f-6fb7ac621e2b@gmail.com/
>>>
>>> If EL1 is allowed to set the security access configuration of the IP
>>> cores doesn't this mean that a backdoor can be opened? E.g. your
>>> secure-boot system configures one I2C IP core to be accessible only from
>>> secure-world S-EL1 (OP-TEE) and after the power-domain was power-cycled
>>> it's accessible from EL1 again. This doesn't seem right. Why should a
>>> user be able to limit the access permissions to an IP core to only be
>>> accessible from secure-world if the IP core is accessible from
>>> normal-world after the power-domain was power-cycled.
>>>
>>> Regards,
>>>   Marco
>> I'm no security expert so please feel free to correct me if I get
>> something wrong.
>>
>> This isn't about S/NS world. The bridge AC doesn't offer any
>> configurations for denying access to peripherals based on S/NS world.
> It does, please see the AIPSTZ_OPACR register definition. The imx-atf of
> sets OPACR registers to 0 (of course), which means that the S/NS is not
> checked _but_ it can be configured.

which bits are you referring to more precisely? because, from the OPACR
register definition we have:

1) TP (Trusted protect) - bit 0 => controls whether the peripheral allows
transactions from an untrusted master. A master is considered trusted if
MTR/MTW (from MPR registers) is set to 1 (MTR means trusted for read,
MTW means trusted for write)

2) WP (Write protect) - bit 1 => controls whether the peripherals allows
write transactions (i.e: is write protected or not)

3) SP (Supervisor protect) - bit 2 => controls whether the master needs
supervisor privilege or not to issue transactions to the peripheral. For
Cortex-A53 this refers to the execution level (EL0 - EL3). There's no S/NS
checks here. EL1-EL3 are supervisor accesses, EL0 is not.

4) BW (Buffer Writes) - bit 3 => some flow control configuration bit I'd assume


>
> Also please see chapter 4.7.6.1 Security Block:
>
> The AIPSTZ contains a security block that is connected to each
> off-platform peripheral. This block filters accesses based on
> write/read, non-secure, and supervisor signals.

yep, but this block is not configured by the AIPSTZ. AFAIK it's configured
by the CSU. So, as far as I understand it, the interaction is as follows:

basically you have the CSU which offers some security-related configurations
(see "Table 4-16 Security Levels" from the section you've mentioned). These
configurations are used by the AIPS bridges to filter transactions.

For example: assume you have peripheral X on AIPS5. The user configures
the CSU such that peripheral X should only accept R/W transactions from
privileged S world. Now, assume Cortex-A53 issues a transaction from
NS EL1 (Linux, for example). The bridge will receive the transaction and
check to see if it's privileged and S world. Since it's not then the transaction
will be aborted.

The AIPS bridge offers no S/NS world-related configuration options. All you can
do with it is:

1) Mark certain masters as "trusted" and block read/writes based on that (via MPR's
MTR/MTW and OPACR's TP)
2) Force transactions to user privilege (via MPR's MPL)
3) Make certain peripherals deny unprivileged transactions (via OPACR's SP)

>
>> AFAIK that's the job of the CSU (central security unit), which is a
>> different IP.
> Please see above.
>
>> Perhaps I shouldn't have used the term "trusted" as it might have
>> ended up creating more confusion? If so, please do let me know so I
>> can maybe add a comment about it in one of the commit messages. In
>> this context, "master X is trusted for read/writes" means "master X is
>> allowed to perform read/write transactions".
> No you didn't confused me but you triggered my interest :) and I started
> to check the (S)TRM.

glad to have picked your interest with this series!

>
>> Even if the bridge is configured to allow read/write transactions from
>> a master (i.e: master is marked as trusted for read/writes) that
>> wouldn't be very helpful.
> We're talking about the IP access permissions, right. If the
> "secure-I2C" is accessible from NS world this would make a difference of
> course.

It wouldn't though. No configuration in the AIPS bridge AC will make the I2C
accesible from NS world.

>
>> You'd still have to bypass the CSU configuration which as far as I
>> understand is also used by the bridge to deny access to peripherals
>> (e.g: if transaction is secure+privileged then forward to peripheral,
>> otherwise abort it). See the "4.7.6.1 Security Block" and "4.7.4 
>> Access Protections" chapters from the IMX8MP RM.
> I have read this too, also that the AIPSTZ can force the mode into
> user_mode regardless of the CSU settings, if I get this correct.
>
> What I don't understand as of now is the interaction of the AIPSTZ and
> the CSU. You can configure different bus-masters within the CSU to be
> S/NS as well as the pheripherals. Now the part which I don't understand
> right now: According the OPACx register description:
>
> x0xx SP0 — This peripheral does not require supervisor privilege level
>            for accesses.
> x1xx SP1 — This peripheral requires supervisor privilege level for
>            accesses. The master privilege level must indicate supervisor
> 	   via the hprot[1] access attribute, and the MPROTx[MPL] control
> 	   bit for the master must be set. If not, the access is
> 	   terminated with an error response and no peripheral access is
> 	   initiated on the IPS bus.
>
> The peripheral can be configured via the AIPSTZ as well. So which IP
> (CSU or AIPSTZ) override the other if the settings don't match, e.g. if
> CSU says: "this I2C controller for secure-world" and the AIPSTZ says:
> "this I2C is for non-secure-world".

the SP bit you've mentioned is used to deny unprivileged transactions.
The privilege is given by the execution level for CA53. EL0 transactions are
unprivileged, EL1-EL3 are privileged, but this can depend based on the type
of access. See Table 7-10 "Cortex-A53 MPCore mode and ARPROT and AWPROT
values" from ARM's Cortex-A53 MPCore Processor Technical Reference Manual
for details.

the bit has nothing to do with S/NS world so there's no overriding the
S/NS world-related policy given by the CSU.

>
>> Given all of this, I think the purpose of this IP's AC is to add some
>> extra, light, security features on top of the CSU.
> Or to override the CSU settings like the MPROTOx values:
>
> xxx0 MPL0 — Accesses from this master are forced to user-mode
>            (ips_supervisor_access is forced to zero) regardless of the
> 	   hprot[1] access attribute.
> xxx1 MPL1 — Accesses from this master are not forced to user-mode. The
>             hprot[1] access attribute is used directly to determine
> 	    ips_supervisor_access.
>
> Can you pleae elaborate a bit more how NXP designed the interaction
> between both the AIPSTZ and the CSU?

I believe this will override the privilege level of the transaction at the
bridge level. This could be useful if you want to, for instance, force
transactions for peripherals under AIPS5 to user but use HPROT[1]
(or the value you've configured via the CSU) for peripherals under AIPS4.
Not sure of an usecase in which you'd want that though.

anyways, hope my comments will shed a bit more light on this.

On 25-03-10, Laurentiu Mihalcea wrote:
> 
> 
> On 3/7/2025 4:39 PM, Marco Felsch wrote:
> > On 25-03-05, Laurentiu Mihalcea wrote:
> >> On 2/27/2025 1:28 PM, Marco Felsch wrote:
> >>> Hi Laurentiu,
> >>>
> >>> On 25-02-26, Marco Felsch wrote:
> >>>> Hi,
> >>>>
> >>>> On 25-02-26, Laurentiu Mihalcea wrote:
> >>>>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >>>>>
> >>>>> The AIPSTZ bridge offers some security-related configurations which can
> >>>>> be used to restrict master access to certain peripherals on the bridge.
> >>>>>
> >>>>> Normally, this could be done from a secure environment such as ATF before
> >>>>> Linux boots but the configuration of AIPSTZ5 is lost each time the power
> >>>>> domain is powered off and then powered on. Because of this, it has to be
> >>>>> configured each time the power domain is turned on and before any master
> >>>>> tries to access the peripherals (e.g: AP, CM7, DSP, on i.MX8MP).
> >>>> My question still stands:
> >>>>
> >>>> Setting these bits requires very often that the core is running at EL3
> >>>> (e.g. secure-monitor) which is not the case for Linux. Can you please
> >>>> provide more information how Linux can set these bits?
> >>> Sorry I didn't noticed your response:
> >>>
> >>> https://lore.kernel.org/all/a62ab860-5e0e-4ebc-af1f-6fb7ac621e2b@gmail.com/
> >>>
> >>> If EL1 is allowed to set the security access configuration of the IP
> >>> cores doesn't this mean that a backdoor can be opened? E.g. your
> >>> secure-boot system configures one I2C IP core to be accessible only from
> >>> secure-world S-EL1 (OP-TEE) and after the power-domain was power-cycled
> >>> it's accessible from EL1 again. This doesn't seem right. Why should a
> >>> user be able to limit the access permissions to an IP core to only be
> >>> accessible from secure-world if the IP core is accessible from
> >>> normal-world after the power-domain was power-cycled.
> >>>
> >>> Regards,
> >>>   Marco
> >> I'm no security expert so please feel free to correct me if I get
> >> something wrong.
> >>
> >> This isn't about S/NS world. The bridge AC doesn't offer any
> >> configurations for denying access to peripherals based on S/NS world.
> > It does, please see the AIPSTZ_OPACR register definition. The imx-atf of
> > sets OPACR registers to 0 (of course), which means that the S/NS is not
> > checked _but_ it can be configured.
> 
> which bits are you referring to more precisely? because, from the OPACR
> register definition we have:
> 
> 1) TP (Trusted protect) - bit 0 => controls whether the peripheral allows
> transactions from an untrusted master. A master is considered trusted if
> MTR/MTW (from MPR registers) is set to 1 (MTR means trusted for read,
> MTW means trusted for write)
> 
> 2) WP (Write protect) - bit 1 => controls whether the peripherals allows
> write transactions (i.e: is write protected or not)
> 
> 3) SP (Supervisor protect) - bit 2 => controls whether the master needs
> supervisor privilege or not to issue transactions to the peripheral. For
> Cortex-A53 this refers to the execution level (EL0 - EL3). There's no S/NS
> checks here. EL1-EL3 are supervisor accesses, EL0 is not.

Argh.. my head mixed the supervisor phrase :/

> 4) BW (Buffer Writes) - bit 3 => some flow control configuration bit I'd assume
> 
> 
> >
> > Also please see chapter 4.7.6.1 Security Block:
> >
> > The AIPSTZ contains a security block that is connected to each
> > off-platform peripheral. This block filters accesses based on
> > write/read, non-secure, and supervisor signals.
> 
> yep, but this block is not configured by the AIPSTZ. AFAIK it's configured
> by the CSU. So, as far as I understand it, the interaction is as follows:
> 
> basically you have the CSU which offers some security-related configurations
> (see "Table 4-16 Security Levels" from the section you've mentioned). These
> configurations are used by the AIPS bridges to filter transactions.
> 
> For example: assume you have peripheral X on AIPS5. The user configures
> the CSU such that peripheral X should only accept R/W transactions from
> privileged S world. Now, assume Cortex-A53 issues a transaction from
> NS EL1 (Linux, for example). The bridge will receive the transaction and
> check to see if it's privileged and S world. Since it's not then the transaction
> will be aborted.
> 
> The AIPS bridge offers no S/NS world-related configuration options. All you can
> do with it is:
> 
> 1) Mark certain masters as "trusted" and block read/writes based on that (via MPR's
> MTR/MTW and OPACR's TP)
> 2) Force transactions to user privilege (via MPR's MPL)
> 3) Make certain peripherals deny unprivileged transactions (via OPACR's SP)

Okay, thanks for the explanation with your input and the the TRM 4.7.6.1
saying:

8<--------------------------------------------------------------
A 3-bit input, 8-bit output translation block can be used such that only
three register bits are required to set the security profile and the
translation block will drive the correct 8-bit configuration vector.
Each peripheral connected to the AIPSTZ would require this translation
block. The top level AIPSTZ has this three bit input line
`csu_sec_level[2:0]' corresponding to each peripheral X.
8<--------------------------------------------------------------

I think that I understood the AIPSTZ user/supervisor now. The master
user/supervisor privileges are provided by the CSU HPx settings and can
be forced to user-mode via the AIPSTZ MPRTOx MPL0 bit.

The remaining bits from the config vector between the CSU and the AIPSTZ
are not taken into account.

Thanks for the clarification!

Regards,
  Marco