- TF-A - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 22nd October 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 22nd October 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Encrypted FIP Support * Presented by Sumit Garg * Summary * Overview of FIP encryption. * Common challenges with firmware encryption implementation and how we addressed those in TF-A. * FIP encryption implementation details. * Follow on Measured Boot Support in TF-A discussion from last meeting (if required) * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 2 months

1
0
0 0

Re: [TF-A] TF-A Tech Forum Agenda @ Thr 8th October 2020 16:00-1700 BST

by Ruchika Gupta

Hi Joanna, Can you please share the presentation of the session on Measured Boot. It is not currently available on the webpage - https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Regards, Ruchika On Tue, 6 Oct 2020 at 22:58, Joanna Farley via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > The next TF-A Tech Forum is scheduled for Thu 8th October 2020 16:00 – > 17:00 (BST). A reoccurring meeting invite has been sent out to the > subscribers of this TF-A mailing list. If you don’t have this please let me > know. > > > > Agenda: > > > > - Measured Boot Support in TF-A > - Presented by Alexei Fedorov and Javier Almansa Sobrino > - Update on the support for Measured Boot in TF-A along with an > overview of test cases for integration with a TPM service > - Optional TF-A Mailing List Topic Discussions > > > > If TF-A contributors have anything they wish to present at any future TF-A > tech forum please contact me to have that scheduled. > > > > Previous sessions, both recording and presentation material can be found > on the trustedfirmware.org TF-A Technical meeting webpage: > https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ > > > > A scheduling tracking page is also available to help track sessions > suggested and being prepared: > https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final > decisions on what will be presented will be shared a few days before the > next meeting and shared on the TF-A mailing list. > > > > Thanks > > > > Joanna > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 3 months

2
1
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

4 years, 3 months

1
0
0 0

commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Biju Das

Hi All, I am porting Renesas RZ/G2M[1] platform to TF-A Master branch(commitid: eeb77da646844) . Initially faced a compilation error [2] which is fixed by using "#define" instead of "static const uint64_t". Then on target, found that BL31 is failed to boot[3], which is fixed by reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes"), see the logs [3]. Q1) Have you seen this issue? Please share your thoughts on this issues. [1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz/… [2] https://lists.trustedfirmware.org/pipermail/tf-a/2020-October/000763.html [3] Failure logs ------------ NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-778-g4fd58b045 NOTICE: BL2: Built : 18:14:35, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 [4]Working logs after reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") -------------------------------------- NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-779-geba02ef39 NOTICE: BL2: Built : 18:16:47, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 U-Boot 2020.10-00535-gd0e9210a2f (Oct 08 2020 - 12:34:09 +0100) CPU: Renesas Electronics R8A774A1 rev 1.3 Model: HopeRun HiHope RZ/G2M with sub board DRAM: 3.9 GiB MMC: mmc@ee100000: 0, mmc@ee160000: 1 Loading Environment from MMC... OK In: serial@e6e88000 Out: serial@e6e88000 Err: serial@e6e88000 Net: eth0: ethernet@e6800000 Hit any key to stop autoboot: 0 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

4 years, 3 months

2
20
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

Hi Biju, Andre, > sctlr_el3 = 0x0000000030c5183a The MMU is still disabled since we're so early in BL31, so nothing preventing us from making an actual access to physical address 0x0. As Andre already noted: > x30 = 0x0000000000000000 > elr_el3 = 0x0000000000000000 > far_el3 = 0x0000000000000000 It looks like we do have an errant null pointer dereference here. If I had to guess, the I-side successfully fetches a 32-bit word from physical address 0x0, but then fails to decode that bit pattern as a valid opcode. This is reported as "unknown reason", like you're seeing: <quote Arm ARM DDI 0487E.a pp D13-2963> This EC code is used for all exceptions that are not covered by any other EC value. This includes exceptions that are generated in the following situations: - ... - Instruction encodings that are unallocated. - ... </quote> Hope that helps, Ash.

4 years, 3 months

2
1
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ash Wilding via TF-A <TF-A(a)lists.trustedfirmware.org> Date: Sunday, 11 October 2020 at 18:53 <...> It looks like we do have an errant null pointer dereference here. <...> Just to clarify, when I say "null pointer dereference": - you may be trampling over your stack, causing you to pop 0x0 into LR and return there; - you may be trampling over your stack, causing you to pop 0x0 into a GPR that is then BLR'd to; - you may be trampling over some other region of memory containing a function pointer, causing you to load 0x0 into a GPR that is then BLR'd to; - etc. Cheers, Ash.

4 years, 3 months

1
0
0 0

Questions raised about Measured Boot + fTPM test case

by Javier Almansa Sobrino

Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

4 years, 3 months

1
0
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Alexei Fedorov

Hi Biju, As you work with Renesas platforms, have you also seen "Renesas rcar-gen3: cert_header_sa6 Compilation Issue" which I reported on the mailing list on 10/12/2018 and is still not fixed? tools\renesas\rcar_layout_create\sa6.c has #include <stdint.h> which causes compilation error on Yocto 3.13: | aarch64-poky-linux-gcc -DRCAR_SA0_SIZE=1 -DRCAR_SA6_TYPE=0 -I../../include/lib/stdlib -D=AARCH64 -c -o sa6.o sa6.c | In file included from sa6.c:7:0: | /home/alexei/Work/Yocto_3.13_20181205/build/tmp/work/h3ulcb-poky-linux/arm-tf/2.0+gitAUTOINC+19b56cf4a2_556d7d9e3b-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory | # include_next <stdint.h> | ^~~~~~~~~~ | compilation terminated. | <builtin>: recipe for target 'sa6.o' failed | make[1]: *** [sa6.o] Error 1 | plat/renesas/rcar/platform.mk:403: recipe for target 'rcar_layout_tool' failed | make: *** [rcar_layout_tool] Error 2 | ERROR: oe_runmake failed There's no compilation error with gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf tool chain, because compiler searches for <stdint.h> in \gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\lib\gcc\aarch64-elf\8.2.1\include finding "stdint.h" with # include_next <stdint.h> and then getting "stdint.h" from gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\aarch64-elf\include folder. Trusted Firmware-A Porting Guide reads that "To avoid subtle toolchain behavioral dependencies, the header files provided by the compiler are not used. The software is built with the ``-nostdinc`` flag to ensure no headers are included from the toolchain inadvertently. ", tools\renesas\rcar_layout_create\makefile has flags defined as: CFLAGS += ${DEFINES} CFLAGS += -I../../include/lib/stdlib and adding "-nostdinc" flag will make gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf compilation fail because ../../include/lib/stdlib is a wrong path (taken from Renesas ARM-TF version 1.5 "tools\dummy_create\makefile") to include\lib\libc\stdint.h for version ARM-TF version 2.0. This issue can be fixed by changing CFLAGS to CFLAGS += -nostdinc \ -I../../../include/lib/libc \ -I../../../include/lib/libc/aarch64 Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Biju Das via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 09 October 2020 08:12 To: Andre Przywara <Andre.Przywara(a)arm.com>; TF-A(a)lists.trustedfirmware.org <TF-A(a)lists.trustedfirmware.org>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>; Joanna Farley <Joanna.Farley(a)arm.com> Cc: Marek Vasut <marek.vasut(a)gmail.com>; Chris Paterson <Chris.Paterson2(a)renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Subject: Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms. Hi Andre, Thanks for the feedback. > Subject: Re: commit 75fab6496e5fce9a11 ("libc: memset: improve > performance by avoiding single byte writes") causing BL31 boot failure on > Renesas RZ/G2 platforms. > > On 08/10/2020 20:05, Biju Das wrote: > > Hi, > > > I am porting Renesas RZ/G2M[1] platform to TF-A Master > > branch(commitid: eeb77da646844) . Initially faced a compilation error [2] > which is fixed by using "#define" instead of "static const uint64_t". > > What is your exact fix? That compilation error sounds like a more serious > issue, I am scratching my head how such a change would really fix things? Looks like this issue is related to toolchain, I was using aarch64-linux-gcc-7 on U-buntu 18.04 Host toolchain. The compilation is error is fixed by the below changes. #define BL31_RO_BASE BL_CODE_BASE #define BL31_RO_LIMIT BL_CODE_END #define BL31_COHERENT_RAM_BASE BL_COHERENT_RAM_BASE #define BL31_COHERENT_RAM_LIMIT BL_COHERENT_RAM_END The warning fix should not lead to compilation error with the old toolchains. It should be backward compatible to the old toolchains right? Please share your views. > And do you see this with mainline? I tried: Yes > $ make bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls.git on origin/master > and it built just fine. Thanks for the hint, After using the toolchain[1], I got the same results as your's. it compiles successfully. So the issue is related to using older tool chains. [1] https://developer.arm.com/tools-and-software/open-source-software/developer… > > > Then on target, found that BL31 is failed to boot[3], which is fixed > > by reverting the commit 75fab6496e5fce9a11 > > ("libc: memset: improve performance by avoiding single byte writes"), see > the logs [3]. > > Mmmh, interesting. Can you build with "DEBUG=1" to get more output from > BL31? Sure Will do and provide feedback. > I see some calls to memset() from code in drivers/renesas/rcar. > Can you add some debug prints at the top of memset() to dump the > parameters on each call? To see what breaks it? OK. > Are you using memset on some I/O memory, by any chance? And that > doesn't support all access types, like 64-bit stores? Will check and let you know. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

2
2
0 0

Forthcoming Trusted Firmware-A 2.4 release

by Manish Badarkhe

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.4 release during the second week of November 2020 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.3 release. As part of this, a release candidate tag will be created and release activities will commence from Friday 30th Oct 2020 (code freeze date). Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR’s) desired to make the 2.4 release are submitted in good time, to be completed by Tuesday 27th Oct 2020. Any major enhancement PR’s still open after that date will not be merged until after the release Please note, there is no guarantee that all patches under review will be merged before the code freeze date. Any patches that don’t make the code freeze date will complete their review and merge post the release date. Thanks Manish Badarkhe

4 years, 3 months

1
0
0 0

Compilation error with commit "ca661a0092c8ead5ac7df57c55fffcc835d9c0b9"

by Biju Das

Hi All, I am getting compilation error with Mainline TFA on renesas platform for bl31 build. Build command: #make CROSS_COMPILE=aarch64-linux-gnu- bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls Q1) Have any one see this issue? Please correct me, if I am doing something wrong. On further investigation, the below commit introduced the issue [1] [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/ren… It gives compilation error " error: initializer element is not constant" for BL_CODE_BASE [2] [2] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/plat/renesas/… BL_CODE_BASE gets its value from linker in [3] [3] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/commo… If you see [4], the initializer element is not constant [4] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/lib/u… Error logs: biju@biju-VirtualBox:~/work/trusted-firmware-a$ CC plat/renesas/rcar/bl31_plat_setup.c plat/renesas/rcar/bl31_plat_setup.c:25:39: error: initializer element is not constant static const uint64_t BL31_RO_BASE = BL_CODE_BASE; ^~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:26:40: error: initializer element is not constant static const uint64_t BL31_RO_LIMIT = BL_CODE_END; ^~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:29:48: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_BASE = BL_COHERENT_RAM_BASE; ^~~~~~~~~~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:30:49: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_LIMIT = BL_COHERENT_RAM_END; ^~~~~~~~~~~~~~~~~~~ Makefile:1109: recipe for target '/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o' failed make: *** [/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o] Error 1 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

4 years, 3 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A