Hi Rockchip platform maintainers,
There's a build issue spotted with GCC11 on rk3399 platform reported here using tip of master: https://developer.trustedfirmware.org/T925
The issue is not breaking the build with earlier gcc versions, but we think the error is legitimate and caused by a mistake in the platform code. Details in the ticket.
Any chance for you to have a look?
Thanks, Olivier.
Hi,
As a PSCI call, MEM_PROTECT which is used to protect against cold
reboot attack, can't be called from TZ-secure. In a situation where at
run time, HLOS in NS-EL1 transfers some buffer that it owns, to a
secure partition then secure partition can't call MEM_PROTECT because
psci_smc_handler will return SMC_UNK if the caller is secure.
Should MEM_PROTECT be available to TZ-secure as well?
Thanks,
Okash
Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A <
tf-a(a)lists.trustedfirmware.org> a écrit :
> Achin,
>
> Yes that’s what I have suspected in the first place, but no harm asking :)
>
>
>
> Tien Fong,
>
> As per discussed, we could probably expose the a compile time option in
> BL31 that expose a command that read/write to the secure domain.
>
> That case, u-boot shell will be able to access secure domain and not need
> to run in EL3.
>
Would you allow an OS to access underlying hypervisor ?
In essence this is what you are asking:
there are architectural services such as kicking off a new cpu that are
supposed to be routed to the right service handler (PSCI) or secure
firmware updates with anti-bricking support....
Could you be more specific on what you want to do and why ?
That may help us advise on achieving your goals while still being
architecturally correct.
>
>
> Thanks
>
>
>
> *From:* Chee, Tien Fong <tien.fong.chee(a)intel.com>
> *Sent:* Tuesday, April 27, 2021 5:01 PM
> *To:* Achin Gupta <Achin.Gupta(a)arm.com>; tf-a(a)lists.trustedfirmware.org;
> Loh, Tien Hock <tien.hock.loh(a)intel.com>
> *Cc:* See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang <
> kok.kiang.hea(a)intel.com>
> *Subject:* RE: Run BL33 (u-boot) in EL3
>
>
>
> Hi Achin,
>
>
>
> Thanks for the feedback.
>
>
>
> This is use case when user doing development, testing and bring up the
> board, they can use this option to run their script on U-Boot shell to
> access these secure region. Once they have finished the development, and
> testing, then user can switch U-Boot into EL2. This flexibility would
> definitely giving some degree of convenience for development and testing.
>
>
>
> Thanks.
>
>
>
> *From:* Achin Gupta <Achin.Gupta(a)arm.com>
> *Sent:* Tuesday, 27 April, 2021 4:38 PM
> *To:* tf-a(a)lists.trustedfirmware.org; Loh, Tien Hock <
> tien.hock.loh(a)intel.com>
> *Cc:* Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang <
> chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com>
> *Subject:* Re: Run BL33 (u-boot) in EL3
>
>
>
> Hi Tien Hock,
>
>
>
> The maintainers will have more thoughts on this but my $0.02 fwiw.
>
>
>
> I cannot see why the Trusted Firmware project should carry any option that
> enables use of EL3 by users who do not care about security. EL3 is not
> meant to run u-boot with a shell that can be used to fiddle with secure
> memory. This flies against the basic security principles that the project
> is built upon.
>
>
>
> cheers,
> Achin
>
>
> ------------------------------
>
> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Loh,
> Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org>
> *Sent:* 27 April 2021 09:02
> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
> *Cc:* Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang <
> chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com>
> *Subject:* [TF-A] Run BL33 (u-boot) in EL3
>
>
>
> Hi,
>
>
>
> I’m maintaining TF-A for Intel SoCFPGA platform.
>
> Would it be possible if we should have the option to run BL33 (u-boot in
> our case) in EL3?
>
>
>
> The Intel SoCFPGA platform u-boot used to handle all SMC calls:
>
> SPL u-boot (EL3) -> u-boot (EL3)
>
> And we have since move to use TF-A’s BL31, thus boot became
> SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2)
>
>
>
> Main reason is that some users would like to keep u-boot at EL3 as they do
> not care about security, and some users wanted to run some debugging
> read/write to secure region in u-boot shell.
>
>
>
> Thanks
>
> Tien Hock
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi Tien Hock,
Did you explored EL3_PAYLOAD_BASE build option. This option enables booting an EL3 payload, if it suits you then u-boot as EL3 payload.
thanks
Manish
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 27 April 2021 20:16
To: Loh, Tien Hock <tien.hock.loh(a)intel.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; See, Chin Liang <chin.liang.see(a)intel.com>; Chee, Tien Fong <tien.fong.chee(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com>
Subject: Re: [TF-A] Run BL33 (u-boot) in EL3
Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> a écrit :
Achin,
Yes that’s what I have suspected in the first place, but no harm asking :)
Tien Fong,
As per discussed, we could probably expose the a compile time option in BL31 that expose a command that read/write to the secure domain.
That case, u-boot shell will be able to access secure domain and not need to run in EL3.
Would you allow an OS to access underlying hypervisor ?
In essence this is what you are asking:
there are architectural services such as kicking off a new cpu that are supposed to be routed to the right service handler (PSCI) or secure firmware updates with anti-bricking support....
Could you be more specific on what you want to do and why ?
That may help us advise on achieving your goals while still being architecturally correct.
Thanks
From: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>
Sent: Tuesday, April 27, 2021 5:01 PM
To: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>>
Cc: See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>>
Subject: RE: Run BL33 (u-boot) in EL3
Hi Achin,
Thanks for the feedback.
This is use case when user doing development, testing and bring up the board, they can use this option to run their script on U-Boot shell to access these secure region. Once they have finished the development, and testing, then user can switch U-Boot into EL2. This flexibility would definitely giving some degree of convenience for development and testing.
Thanks.
From: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>>
Sent: Tuesday, 27 April, 2021 4:38 PM
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>>
Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>>
Subject: Re: Run BL33 (u-boot) in EL3
Hi Tien Hock,
The maintainers will have more thoughts on this but my $0.02 fwiw.
I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon.
cheers,
Achin
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>
Sent: 27 April 2021 09:02
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>
Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>>
Subject: [TF-A] Run BL33 (u-boot) in EL3
Hi,
I’m maintaining TF-A for Intel SoCFPGA platform.
Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3?
The Intel SoCFPGA platform u-boot used to handle all SMC calls:
SPL u-boot (EL3) -> u-boot (EL3)
And we have since move to use TF-A’s BL31, thus boot became
SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2)
Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell.
Thanks
Tien Hock
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
[https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
Hi Tien Hock,
The maintainers will have more thoughts on this but my $0.02 fwiw.
I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon.
cheers,
Achin
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 27 April 2021 09:02
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com>
Subject: [TF-A] Run BL33 (u-boot) in EL3
Hi,
I’m maintaining TF-A for Intel SoCFPGA platform.
Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3?
The Intel SoCFPGA platform u-boot used to handle all SMC calls:
SPL u-boot (EL3) -> u-boot (EL3)
And we have since move to use TF-A’s BL31, thus boot became
SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2)
Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell.
Thanks
Tien Hock
Hi,
I am trying to enable SPM on iMX8MP platform, which is cortex-A53. The
BL2 is already enabled and the dts file is needed. But I am not sure
how to write below dts information when I referencing
fvp_spmc_manifest.dts. Could you help to give some suggestion or where
should I find the anwsers?
1. Is fvp_spmc_manifest.dts enough to enable SPM? I see there are dts
files, such as fvp_fw_config.dts. What's necessary dts nodes to enable
SPM?
2. Does vcpu_count means CPU number?
3. I see load_address of attribute is optee-os load address. But I do
not know how should I decide the load addresses of hypervisors. Is
this address decided by virtual machine, or it is decided in runtime?
I cannot find the 0x7100000 in trusted-services project.
4. I am confused on "Secure Partitions are bundled as independent
package files" in below link. Does this bundle package means fip
image, or into another file by jason file? Could you help point to the
files and image generation command?
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/compo…
Regards,
Jun
Hi,
I'm maintaining TF-A for Intel SoCFPGA platform.
Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3?
The Intel SoCFPGA platform u-boot used to handle all SMC calls:
SPL u-boot (EL3) -> u-boot (EL3)
And we have since move to use TF-A's BL31, thus boot became
SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2)
Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell.
Thanks
Tien Hock
Hi all!
We are developing a product around the rk3399 Theobroma Q7 module. For
power savings, we need S3 sleep (suspend-to-ram).
As far as I know, the heart of this is in ATF code. We have linux kernel
5.4, which starts the process nicely, drives down all the other cores
and finally calls for the psci suspend. We have wakeup on irq, and it
sure wakes up, but does a reset from the very beginning. So no context
saving resume.
I have tried the newest on the ATF git, with a newish mainline uboot. I
suppose the role of uboot is not that important here.
What should I look at to find the problem? Has someone got the Q7 module
done S3 ok?
Finally, how do I get some debug uart output from ATF code?
Thanks for any hints!
Mika Penttilä
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup()
________________________________________________________________________________________________________
*** CID 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup()
90 int status, ret = 0;
91
92 status = pm_ipi_init(primary_proc);
93
94 if (status < 0) {
95 INFO("BL31: PM Service Init Failed, Error Code %d!\n", status);
>>> CID 370380: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value from "status" to "ret" here, but that stored value is overwritten before it can be used.
96 ret = status;
97 } else {
98 pm_up = true;
99 }
100
101 /*
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…