linux-kernel - Re: [PATCH v1] arm64: dts: meson-axg: reserve memory region for Amlogic TrustOS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 5 Aug 2022 13:42:53 +0000
From:   Dmitry Rokosov <DDRokosov@...rdevices.ru>
To:     Jerome Brunet <jbrunet@...libre.com>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "khilman@...libre.com" <khilman@...libre.com>,
        "martin.blumenstingl@...glemail.com" 
        <martin.blumenstingl@...glemail.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-amlogic@...ts.infradead.org" 
        <linux-amlogic@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        kernel <kernel@...rdevices.ru>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] arm64: dts: meson-axg: reserve memory region for
 Amlogic TrustOS

Hello Jerome,

Thank you for the feedback.

On Fri, Aug 05, 2022 at 10:03:34AM +0200, Jerome Brunet wrote:
> 
> On Thu 04 Aug 2022 at 16:52, Dmitry Rokosov <DDRokosov@...rdevices.ru> wrote:
> 
> > For the all AXG SoC based boards, which run Amlogic vendor ATF and
> > TrustOS this memory region 0x5300000-0x6300000 is reserved by BL32,
> > so tag it as no-map in the kernel iomem.
> 
> This may be true for the boards you have seen so far but not all ship
> with this specific AML TEE. Some don't have TEE at all, other may have
> different TEE regions.
> 
> 16 MB may be a significant part of the available memory on some AXG
> devices. Reserving that memory on all AXG devices, regardless of what is
> actually running does not seem appropriate.
> 
> I know the same has been done for other devices but I don't think we should
> continue to do so. This should be set either
> * per device if it is fixed
> * dynamically by the bootloader depending on the ATF (which is probably better)
> 

I agree with you, *.dtsi is a common device tree base file which is
included in the all board trees. But looks like I don't understand meson
dtsi policy about TEE reserved memory regions. I mean g12 and gx dtsi
have statically defined TrustOS regions inside, and all meson dtsi have
hardcoded ATF regions. All of these regions are aligned with Amlogic ATF
and Amlogic Trust OS reserved memory addresses. And if I want to use
upstream ATF or optee build for Amlogic board, I need to patch dtsi file,
which is not right way as you mentioned.

If we want to use per-board TEE memory regions definitions I suppose we
need to move secos reserved ranges from gx and g12 dtsi files and move
all secmon definitions from all meson dtsi files to appropriate board
dtses (or mark them with status = "disable").

What do you think?

> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@...rdevices.ru>
> > ---
> >  arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > index 3f5254eeb47b..1fa0d3805969 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > @@ -142,6 +142,12 @@ secmon_reserved: secmon@...0000 {
> >  			reg = <0x0 0x05000000 0x0 0x300000>;
> >  			no-map;
> >  		};
> > +
> > +		/* 16 MiB reserved for Amlogic Trust OS (BL32) */
> > +		secos_reserved: secos@...0000 {
> > +			reg = <0x0 0x05300000 0x0 0x1000000>;
> > +			no-map;
> > +		};
> >  	};
> >  
> >  	scpi {
> 

-- 
Thank you,
Dmitry