Message-ID: <20250307143956.aft3xolakts3nlja@pengutronix.de>
Date: Fri, 7 Mar 2025 15:39:56 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: Laurentiu Mihalcea <laurentiumihalcea111@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Daniel Baluta <daniel.baluta@....com>,
	Shengjiu Wang <shengjiu.wang@....com>, Frank Li <Frank.li@....com>,
	imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] imx8mp: add support for the IMX AIPSTZ bridge

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

Powered by blists - more mailing lists