- TF-M - lists.trustedfirmware.org

by Kevin Townsend

tl;dr: unable to connect to MPS2+ AN521 with JLink and perform a soft reset to halt at NSPE init, and debug an init issue. Connect via SWD fails, connect via JTAG seems OK, but soft reset requests consistently fail, preventing meaningful debug/trace of the code. Looking for advice on known-good debug setup with GDB and Linux. Full explanation follows: I'm currently working on an application with the following setup: - TF-M (latest) running in the secure processing environment - Zephyr running in the NSPE - PSA FF APIs to communicate between PEs I've run into a HW problem with the UART peripheral that I need to debug, but using a J-Link has been problematic, and I was curious if anyone else has had any success with GDB or JLinkExe and the MPS2+. To debug, I currently do the following: - Copy a valid TF-M + Zephyr and BL2 image to the MPS2+ - Physically reset the MPS2+ (AN521) - Wait for the image to start up (based on serial output) - Connect the debugger - Attempt to reset I get the following output at connect (entering the 'connect' command at the J-Link prompt): NOTE: I've been unable to get SWD to work, and had to fall back to JTAG for the interface. ---------------------------------------- $ JLinkExe -device Cortex-M33 -if jtag -speed auto SEGGER J-Link Commander V6.44i (Compiled May 17 2019 17:38:03) DLL version V6.44i, compiled May 17 2019 17:37:52 Connecting to J-Link via USB...O.K. Firmware: J-Link V9 compiled May 17 2019 09:50:41 Hardware version: V9.10 S/N: 609100327 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.011V Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect JTAGConf>connect ERROR while parsing value for IRPre. Using default: -1. ERROR while parsing value for DRPre. Using default: -1. Device "CORTEX-M33" selected. Connecting to target via JTAG TotalIRLen = 4, IRPrint = 0x01 JTAG chain detection found 1 devices: #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP Scanning AP map to find all available APs AP[3]: Stopped AP scan as end of AP map has been reached AP[0]: APB-AP (IDR: 0x54770002) AP[1]: AHB-AP (IDR: 0x84770001) AP[2]: AHB-AP (IDR: 0x84770001) Iterating through AP map to find AHB-AP to use AP[0]: Skipped. Not an AHB-AP AP[1]: Core found AP[1]: AHB-AP ROM base: 0xF0008000 CPUID register: 0x410FD211. Implementer code: 0x41 (ARM) Found Cortex-M33 r0p1, Little endian. FPUnit: 8 code (BP) slots and 0 literal slots Security extension: implemented Secure debug: enabled CoreSight components: ROMTbl[0] @ F0008000 ROMTbl[0][0]: F0009000, CID: B105900D, PID: 000BB9A4 GPR ROMTbl[0][1]: E00FF000, CID: B105100D, PID: 000BB4C9 ROM Table ROMTbl[1] @ E00FF000 ROMTbl[1][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 ROMTbl[1][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT ROMTbl[1][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB ROMTbl[1][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM ROMTbl[1][5]: E0041000, CID: B105900D, PID: 001BBD21 ETM ROMTbl[1][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI Cortex-M33 identified. ---------------------------------------- But any attempt to perform a soft reset fails, which makes debugging the init code problematic: ---------------------------------------- J-Link>r 0 Reset delay: 0 ms Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via AIRCR.SYSRESETREQ. Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set). Reset: Using fallback: Reset pin. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via reset pin Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). Reset: Reconnecting and manually halting CPU. AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 ************************** WARNING: CPU could not be halted ************************** Reset: Core did not halt after reset, trying to disable WDT. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via reset pin Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). Reset: Reconnecting and manually halting CPU. AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 ************************** WARNING: CPU could not be halted ************************** ****** Error: Could not find core in Coresight setup ---------------------------------------- If anyone is using a J-Link or J-Trace and ideally GDB to do any meaningful debugging or tracing on the MPS2+ any suggestions on proper setup would be valuable, and I'm happy to document an eventual working config for inclusion in the project doc files. Barring that, an alternative GDB-based setup would be useful if someone has a known-good solution? Best regards, Kevin Townsend

6 years, 2 months

1
0
0 0

Re: [TF-M] Changes to CI for python dependencies

by Kevin Townsend

Hi Minos, Thanks for the detailed reply/explanation. This sounds similar to the CI setup for Zephyr where I test changes locally first. I'm happy to put together a change request for this, based on any feedback here (if it's deemed worth merging in, etc.): https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 Best regards, Kevin On Mon, 5 Aug 2019 at 15:34, Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > The CI comprises of three modules. The Jenkins logic, the Python Scripts and the docker build slave. > > > The environment is provided by the docker build slave and provisioned into the pipeline flow when the venv is created for each stage: > > virtualenv -p python3 ${VENV_P3_NAME} --system-site-packages > > No requirements are installed at the Jenkins Stage, but if needed as an one-off (i.e. for staging purposes), the design supports it. > > > The case for installing Python requirements on the fly using requirements.txt > > > Extending requirements dynamically on the fly, can be quite a challenge due to the way Jenkins handles the absolute resolution of workspace directory on each step. In short Python’s virtual-environment stores the configuration paths in absolute format, while Jenkins is not guaranteed to give you the same reference to a working directory in consecutive calls in the pipeline. > > So if you create a venv at stage 1, which evaluates ~/ as /server/workspace/fubar-job/venv/.. and then attempt to call it in a following parallel step, the code may be located at /server/workspace/1/fubar-job/venv > > At this point you can either create the VENV in each stage, and reinstall the requirements, effectively wasting bandwidth or hack it by piping everything in SED before activating to ensure the path is resolved correctly. > > For that purposes the ci-scripts level requirements.txt will be deprecated in the next feature update. > > > How should a user access or modify the TF-M Build environment. > > > Environment will be established at the docker build stage. > > https://review.trustedfirmware.org/admin/repos/ci/dockerfiles > > And more specifically the requirements for Python3 in this file: > > https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… > > After it has been updated and merged you should raise a ticket and request the image to get rebuilt, or if it is not very critical, wait for some other party change to trigger the build. > > The process requires creating local docker image, meant to test your changes but also allowing you to access the TF-M build environment as deployed on the CI. You can do that following the steps below: > > > # Get the docker image > > $ git clone https://review.trustedfirmware.org/ci/dockerfiles && cd dockerfiles/xenial-amd64-tf-m-build > > # Edit the entry point to convert it not to be a jenkins-slave > > $ vi Dockerfile > > # change ENTRYPOINT ["/usr/local/bin/jenkins-slave"] to ENTRYPOINT [/bin/bash"], save exit > > # Build the image > > $ docker build ./ > > # Find the image hash id > > $ docker image ls > > # Run an interactive bash shell, mounting a local directory as /opt/openci in instance (if required to share files) > > $ docker run -it --name tf-m-build-env -v /YOUR_CUSTOM_PATH:/opt/openci 10bcb173cd39 > > # You can relaunch that instance in the future by starting it again. > > $ docker start && docker -exec -it tf-m-build-env /bin/bash > > > > Please let me know if you need more clarity or guidance on how to handle modifications on the CI. > > > Regards, > > Minos Galanakis > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 August 2019 14:57 > To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Changes to CI for python dependencies > > +Minos now > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M > Sent: 02 August 2019 14:47 > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes to CI for python dependencies > > Minos, could you have a look at this? > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M > Sent: 02 August 2019 12:44 > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Changes to CI for python dependencies > > In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 > > The change fails in CI, however, due to the missing cryptography module in the CI build environment: > https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… > > This brings up the following issues: > > - How can/should changes be made to the CI build environment? > - Can the overall TF-M installation process be improved automating > Python module installation via a requirements.txt file? > > Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). > > This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. > > I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

2
1
0 0

Re: [TF-M] independent device driver model working along side SPM

by Miklos Balint

Hi Manoj, Please elaborate on the problem you are seeing and the steps you want to take so we can consider if it's something TF-M is in the process of addressing or if it is out of scope. On first read I feel there's a contradiction: The point of having TF-M - or any secure "supervising entity" - in the system is that it has awareness of the goings-on in the system, understands the states of parallel contexts that are supported by the hardware, to control its security aspects. Having a device driver "not plugged in TF-M" would, on the face of it, defeat the purpose of TF-M as a management entity, and the device driver would need not only to handle its own threat vectors, but any potential collisions with TF-M's understanding and control of the system state, making it, in effect, part of the management entity. So rather than the driver being not plugged in, I guess what we need to work out is how TF-M can be extended to cover the type of use case you are working on, without compromising the holistic security model that TF-M implements - but there's no one-size-fits-all solution. Thanks and regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of R, Manoj via TF-M Sent: 05 July 2019 10:24 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] independent device driver model working along side SPM Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

2
5
0 0

Re: [TF-M] Changes to CI for python dependencies

by Minos Galanakis

The CI comprises of three modules. The Jenkins logic, the Python Scripts and the docker build slave. The environment is provided by the docker build slave and provisioned into the pipeline flow when the venv is created for each stage: virtualenv -p python3 ${VENV_P3_NAME} --system-site-packages No requirements are installed at the Jenkins Stage, but if needed as an one-off (i.e. for staging purposes), the design supports it. The case for installing Python requirements on the fly using requirements.txt Extending requirements dynamically on the fly, can be quite a challenge due to the way Jenkins handles the absolute resolution of workspace directory on each step. In short Python’s virtual-environment stores the configuration paths in absolute format, while Jenkins is not guaranteed to give you the same reference to a working directory in consecutive calls in the pipeline. So if you create a venv at stage 1, which evaluates ~/ as /server/workspace/fubar-job/venv/.. and then attempt to call it in a following parallel step, the code may be located at /server/workspace/1/fubar-job/venv At this point you can either create the VENV in each stage, and reinstall the requirements, effectively wasting bandwidth or hack it by piping everything in SED before activating to ensure the path is resolved correctly. For that purposes the ci-scripts level requirements.txt will be deprecated in the next feature update. How should a user access or modify the TF-M Build environment. Environment will be established at the docker build stage. https://review.trustedfirmware.org/admin/repos/ci/dockerfiles And more specifically the requirements for Python3 in this file: https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… After it has been updated and merged you should raise a ticket and request the image to get rebuilt, or if it is not very critical, wait for some other party change to trigger the build. The process requires creating local docker image, meant to test your changes but also allowing you to access the TF-M build environment as deployed on the CI. You can do that following the steps below: # Get the docker image $ git clone https://review.trustedfirmware.org/ci/dockerfiles && cd dockerfiles/xenial-amd64-tf-m-build # Edit the entry point to convert it not to be a jenkins-slave $ vi Dockerfile # change ENTRYPOINT ["/usr/local/bin/jenkins-slave"] to ENTRYPOINT [/bin/bash"], save exit # Build the image $ docker build ./ # Find the image hash id $ docker image ls # Run an interactive bash shell, mounting a local directory as /opt/openci in instance (if required to share files) $ docker run -it --name tf-m-build-env -v /YOUR_CUSTOM_PATH:/opt/openci 10bcb173cd39 # You can relaunch that instance in the future by starting it again. $ docker start && docker -exec -it tf-m-build-env /bin/bash Please let me know if you need more clarity or guidance on how to handle modifications on the CI. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 02 August 2019 14:57 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to CI for python dependencies +Minos now -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 02 August 2019 14:47 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to CI for python dependencies Minos, could you have a look at this? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 02 August 2019 12:44 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Changes to CI for python dependencies In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] PSA Storage API

by Jamie Fox

Hi Andrej, Alignment with the PSA 1.0.0 APIs is on the TF-M roadmap for next quarter: https://developer.trustedfirmware.org/w/tf_m/planning/ The "release" branch of the psa-arch-tests repo should be used for functional API certification. TF-M is compatible with that branch. Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 05 August 2019 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Storage API Just only FYI: The latest PSA Test Suite has been switched to a newer version of PSA Storage API: https://github.com/ARM-software/psa-arch-tests/issues/105 Best regards, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

PSA Storage API

by Andrej Butok

Just only FYI: The latest PSA Test Suite has been switched to a newer version of PSA Storage API: https://github.com/ARM-software/psa-arch-tests/issues/105 Best regards, Andrej Butok

6 years, 2 months

1
0
0 0

Re: [TF-M] Changes to CI for python dependencies

by Antonio De Angelis

+Minos now -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 02 August 2019 14:47 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to CI for python dependencies Minos, could you have a look at this? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 02 August 2019 12:44 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Changes to CI for python dependencies In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Changes to CI for python dependencies

by Antonio De Angelis

Minos, could you have a look at this? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 02 August 2019 12:44 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Changes to CI for python dependencies In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Changes to CI for python dependencies

by Kevin Townsend

In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend

6 years, 3 months

1
0
0 0

tfm_ns_interface functions refactoring

by Kevin Peng (Arm Technology China)

Hi, I made some changes to the tfm_ns_interface_ functions. They have common implementations that call os_wrapper_ functions. With these changes, RTOSes only need to implement the OS dependent functions defined in os_wrappers rather than the tfm_ns_interface_ functions. There are several changes with a same topic: https://review.trustedfirmware.org/q/topic:%22refine_ns_interface_functions… Please help on reviewing. Thanks. - Kevin

6 years, 3 months

1
0
0 0

Non-secure SVC handling

by Miklos Balint

[from thread: RE: Adding a platform specific tfm_svc_number_t] Hi Andrej, Please note that non-secure SVC handling is independent of secure SVC handling - the two are implemented separately in the code base and hardware resources are banked for their execution. The original discussion is about secure SVC handling type and functions, which are unrelated to NS RTOS dependency on (NS) SVC. I'm starting a separate discussion thread for NS SVC occupancy to avoid blurring the lines between the two. Please note that any example code in the TF-M repository on NS SVC handling is for demonstration purposes and not, strictly speaking, part of TF-M core implementation. It shows how a non-secure privileged entity needs to register a client ID to the SPM on task creation, if multiple client IDs are managed by the RTOS. Whether a specific implementation uses SVC or another method for running the corresponding privileged code is out of scope of the design, only one possible option is shown, but this is an RTOS-specific problem. Meaning that in an RTOS where the adaptation layer mustn't use SVC and is relying on some other method, there's no design limitation in TF-M that is in conflict with that - the implementation can be adjusted in line with the RTOS's method of choice, but where the NS RTOS has no such restriction, the adaptation layer can rely on SVC for this feature. Thanks Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 26 July 2019 08:29 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, July 26, 2019 3:49 AM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC > enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as > platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C42c1df29f3b84ac62f5708d7116b749e%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636997025530401902&sdata=vO0tq34jt > zFFn9D3cnrDP3a4fnrkq4h5jvzZmob2HnU%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
2
0 0

[RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Hi, Several patches for code restructure is coming. Before I post the gerrit items, I want to collect your feedback on this. These changes contain: - Move header files into dedicated directory for easy include, and clean the included headers in sources; - Change some files' name to let them make more sense. - Move SPM related files into 'spm' folder instead of putting them in 'core'. - Move some interface files into 'ns_callable' since they are interfaces. - Remove 'ipc' folder after all files in it are well arranged. I will try to do these patches together so they can be merged together. But before that I want to request for comments about this, feel free to reply in this thread or comment on the task (add yourself if you are missing as subscribers): https://developer.trustedfirmware.org/T426 BR /Ken

6 years, 3 months

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

As a follow-up, mcuboot has removed the pycrypto dependency, so I will put an update together for TF-M for review: https://github.com/JuulLabs-OSS/mcuboot/tree/master/scripts/imgtool Best regards, Kevin On Wed, 31 Jul 2019 at 16:27, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > As part of an effort to enable automatic builds of TF-M in Zephyr, > I've been trying to get the TF-M + Zephyr S/NS images building and > passing on Zephyr's CI system. > > The only missing requirements for building TF-M in a clean > Zephyr SDK 0.10.1 based environment is the pycrypto module, which > is used in the imgtool.py utility, specifically: > > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… > > My concern is that this module is no longer actively maintained > (last release was 2013!), and it seems like a poor decision to rely > on something that isn't actively maintained when more recent > alternative are available. > > Is there a specific reason to keep this module in the script in favour > of something more modern? > > Best regards, > Kevin > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Antonio De Angelis

Hi Kevin, We are open to scope what would be needed to move to more supported alternatives, for example: https://pypi.org/project/cryptography/ If you have any specific idea, please submit it. As far as I can see now, there is not a specific reason to stick with the old pycrypto module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 31 July 2019 15:28 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

I cherry-picked the commit into my build area and confirmed that it behaves properly. Alan > On Jul 29, 2019, at 7:57 PM, DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Looks fine to me! > > On Jul 29, 2019, at 7:19 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: > > Hi, > > The related patch is pushed into https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1669/ > Please help to review if you have time. > > Thanks, > Summer > ________________________________ > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Tuesday, July 30, 2019 6:45 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: RE: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > It would be good to get this fix into master ASAP so master doesn’t remain broken for long. > > > > Alan > > > > From: Summer Qin (Arm Technology China) [mailto:Summer.Qin@arm.com] > Sent: Sunday, July 28, 2019 11:18 PM > To: DeMars, Alan > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Hi Alan, > > > > Yeah, I see your proposed changes in the email. > > We will make the corrections under my task T435. > > > > > > Thanks, > > Summer > > > > ________________________________ > > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Monday, July 29, 2019 11:30 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Summer, > > The email I sent with the attachment was bounced back so I sent another one afterwards that detailed the changes I had to make. I’d rather someone on your team make the corrections to make sure they’re sufficient. > > Alan > >> On Jul 28, 2019, at 7:41 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: >> >> Hi Alan, >> >> Thanks for pointing out this issue. >> >> The patch related to PSA APIs alignment task is the first patch to align the PSA APIs, we will have some following patches to update. >> In your last email, I didn't see the attachment, maybe blocked by the system. If it is convenient for you, could you push your patch to https://review.trustedfirmware.org , or you can create one ticket in https://developer.trustedfirmware.org and upload your changes as attachment in the new created task. Attached the change under my task T435 is also OK. We can help to submit the changes for you. >> >> >> Thanks, >> Summer >> >> On 7/28/19, 4:39 PM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: >> >> I found several other code points in tfm_svcalls.c that need to be enhanced to handle 'type' >= PSA_IPC_CALL. >> >> Attached is my modified tfm_svcalls.c file. With these modifications, the 'type' argument makes its way through the system without causing tfm_panic() to be invoked. >> >> Alan >> >> -----Original Message----- >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M >> Sent: Friday, July 26, 2019 2:28 PM >> To: Ken Liu (Arm Technology China) >> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> >> Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: >> >> msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Should be: >> >> msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. >> >> Alan >> >> From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] >> Sent: Thursday, July 25, 2019 7:14 PM >> To: DeMars, Alan >> Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> Summer-ARM closed this task as "Resolved". >> >> >> TASK DETAIL >> https://developer.trustedfirmware.org/T435 >> >> EMAIL PREFERENCES >> https://developer.trustedfirmware.org/settings/panel/emailpreferences/ >> >> To: Summer-ARM >> Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> >> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, The interface call from ' tfm_core_init() ' to 'tfm_spm_hal_set_secure_irq_priority()' is planned to be left there as it is now. If a certain platform implementation doesn't allow interrupt priorities to be set, it can leave the implementation of 'tfm_spm_hal_set_secure_irq_priority()' function empty. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 30 July 2019 01:10 To: Adrian Shaw <Adrian.Shaw(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] including platform specific interrupt definitions Adrian, Yes, I noticed this. I guess that means that the handler name will be derived from the 'source' string. Sadly, it appears that the CMSIS convention for naming IRQ numbers is 'PeripheralX_IRQn'. Given your handler naming convention, that means that the handler names I have to put in my platform's vector table must be 'PeripheralX_IRQn_Handler'. I prefer 'PeripheralX_Handler' myself and that is what I've telegraphed to our development team. I'm thinking we will honor the PSA FF convention that if ONLY the 'source' attribute is provided for an IRQ, your name mangling rule will be followed for generating the ISR function name. Additionally, we will modify the template such that if a custom attribute of 'handler_name' (or some such) is ALSO provided, we will use our own name mangling rules for generating the ISR function name so that we are free to populate the vector table with whatever function names we want. Similarly, it appears that support for the 'tfm_irq_priority' attribute will be a platform-specific extension. Does this mean that the logic currently in tfm_core_init() that calls tfm_spm_hal_set_secure_irq_priority() for each interrupt will be removed from the standard code base? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Adrian Shaw via TF-M Sent: Monday, July 29, 2019 7:49 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Just as a heads up for future consideration. In the final version of the PSA-FF spec we replaced the `line_num` and `line_name` attributes with a new single attribute called “source”. You can use numbers or string identifiers with it (see change log in Appendix E of PSA-FF 1.0.0). Best, Adrian > On 29 Jul 2019, at 15:37, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > When I created the templates, I was thinking that it is a good idea to have the '_Handler' postfix on the privileged interrupt handler names in both cases (e.g. 'line_num' or 'line_name' is provided.). This would keep the names aligned to the current pattern applied in the existing platform implementations. > > If I understand your proposal correctly, that means, in case a 'line_name' is provided in the partition manifest, there would be two different entities in the code, which are referred by the same name: > - The IRQ handler function > - A macro which is substituted to the number of that IRQ line > > I'm not completely sure that it will not happen that the header file containing the macro gets included in a file that defines or declares the function which would break the privileged handler declaration or definition. Although I didn't check this situation occurs in the current implementation. > > Is my understanding correct? Is there a benefit of this proposal that I missed? > > Thanks, > Mate > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: 22 July 2019 17:23 > To: tf-m(a)lists.trustedfirmware.org; Mate Toth-Pal > <Mate.Toth-Pal(a)arm.com> > Subject: RE: including platform specific interrupt definitions > > After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: > > 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" > > 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" > > 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. > > I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': > > {% if handler.line_num %} > void irq_{{handler.line_num}}_Handler(void) > {% elif handler.line_name %} void > {{handler.line_name}}_Handler(void) > > To this: > > {% if handler.line_name %} > void {{handler.line_name}}(void) > {% elif handler.line_num %} void > {{handler.line_num}}_Handler(void) > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of DeMars, Alan via TF-M > Sent: Friday, July 19, 2019 1:36 PM > To: Mate Toth-Pal > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Mate, > > Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. > > Thanks again, > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Mate Toth-Pal via TF-M > Sent: Friday, July 19, 2019 1:22 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Hi Alan, > > I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ > This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. > > Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. > This replaces the manually created IPC model signal definitions to the generated signals: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ > > This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ > > This, and the related changes remove the manually created signal files. > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ > > So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. > > As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. > > Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. > > Regards, > Mate > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: 19 July 2019 18:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] including platform specific interrupt definitions > > I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. > > What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: PSA API prototype update

by Mate Toth-Pal

Hi Alan, Currently there are no plans to deprecate the 'tfm_irq_priority' optional attribute. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 25 July 2019 04:44 To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: PSA API prototype update Hi Alan, These attributes should be already included in 'test/test_services/tfm_irq_test_service_1' of latest master, you can check the sources. The alignment is a big task and the patch mentioned in this mail thread is the first one of prototype change. The whole FF 1.0.0 alignment (behaviors change e.g.) would come step by step later on. And the interrupt priority -- let me check with interrupt designers to know more details. Current from my point of view it is platform defined setting which is out of FF scope. Thanks. -Ken > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, July 25, 2019 9:53 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [EXTERNAL] RE: PSA API prototype update > > Ken, > > Will support for the new “source” attribute in “irqs” be included in > this API alignment? If not, when might it be supported? Also, is the “irqs” “priority” > attribute being deprecated? > > Alan > > > On Jul 24, 2019, at 6:12 PM, Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com> wrote: > > > > Hi Alan, > > > > Should by this weekend or early next week, depends on if there are > > new > comments. > > > > Thanks. > > > > -Ken > > > >> -----Original Message----- > >> From: DeMars, Alan <ademars(a)ti.com> > >> Sent: Wednesday, July 24, 2019 11:17 PM > >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > >> Cc: tf-m(a)lists.trustedfirmware.org > >> Subject: RE: PSA API prototype update > >> > >> When do you anticipate that this patch will be merged to master? > >> > >> -----Original Message----- > >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On > >> Behalf Of Ken Liu (Arm Technology China) via TF-M > >> Sent: Tuesday, July 23, 2019 11:17 PM > >> To: tf-m(a)lists.trustedfirmware.org > >> Cc: nd > >> Subject: [EXTERNAL] [TF-M] PSA API prototype update > >> > >> Hi, > >> > >> A patch is pushed for couple of days reveals the update on PSA API > >> prototype and its related caller change: > >> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 > >> > >> The most obvious part is a new parameter member 'type' is > >> introduced in 'psa_call'. This is the first step of our upgrading > >> to the latest PSA Firmware Framework Specification. The API > >> internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. > >> > >> The callers included in TF-M has been updated in this patch. > >> Developers who developed extra services should mention this change > >> and update PSA API related sources. > >> Any feedback please comment under the patch, or reply to this mail thread. > >> > >> Thanks. > >> > >> -Ken > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Uniform Secure Service Signature

by Mate Toth-Pal

Hi Alan, Yes, this should happen as part of the FF 1.0.0 alignment effort. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 25 July 2019 23:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Uniform Secure Service Signature With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by Summer Qin (Arm Technology China)

Hi Alan, Thanks for pointing out this issue. The patch related to PSA APIs alignment task is the first patch to align the PSA APIs, we will have some following patches to update. In your last email, I didn't see the attachment, maybe blocked by the system. If it is convenient for you, could you push your patch to https://review.trustedfirmware.org , or you can create one ticket in https://developer.trustedfirmware.org and upload your changes as attachment in the new created task. Attached the change under my task T435 is also OK. We can help to submit the changes for you. Thanks, Summer On 7/28/19, 4:39 PM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: I found several other code points in tfm_svcalls.c that need to be enhanced to handle 'type' >= PSA_IPC_CALL. Attached is my modified tfm_svcalls.c file. With these modifications, the 'type' argument makes its way through the system without causing tfm_panic() to be invoked. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Friday, July 26, 2019 2:28 PM To: Ken Liu (Arm Technology China) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr); Should be: msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr); Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. Alan From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment Summer-ARM closed this task as "Resolved". TASK DETAIL https://developer.trustedfirmware.org/T435 EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/ To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
5
0 0

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

Adrian, Yes, I noticed this. I guess that means that the handler name will be derived from the 'source' string. Sadly, it appears that the CMSIS convention for naming IRQ numbers is 'PeripheralX_IRQn'. Given your handler naming convention, that means that the handler names I have to put in my platform's vector table must be 'PeripheralX_IRQn_Handler'. I prefer 'PeripheralX_Handler' myself and that is what I've telegraphed to our development team. I'm thinking we will honor the PSA FF convention that if ONLY the 'source' attribute is provided for an IRQ, your name mangling rule will be followed for generating the ISR function name. Additionally, we will modify the template such that if a custom attribute of 'handler_name' (or some such) is ALSO provided, we will use our own name mangling rules for generating the ISR function name so that we are free to populate the vector table with whatever function names we want. Similarly, it appears that support for the 'tfm_irq_priority' attribute will be a platform-specific extension. Does this mean that the logic currently in tfm_core_init() that calls tfm_spm_hal_set_secure_irq_priority() for each interrupt will be removed from the standard code base? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Adrian Shaw via TF-M Sent: Monday, July 29, 2019 7:49 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Just as a heads up for future consideration. In the final version of the PSA-FF spec we replaced the `line_num` and `line_name` attributes with a new single attribute called “source”. You can use numbers or string identifiers with it (see change log in Appendix E of PSA-FF 1.0.0). Best, Adrian > On 29 Jul 2019, at 15:37, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > When I created the templates, I was thinking that it is a good idea to have the '_Handler' postfix on the privileged interrupt handler names in both cases (e.g. 'line_num' or 'line_name' is provided.). This would keep the names aligned to the current pattern applied in the existing platform implementations. > > If I understand your proposal correctly, that means, in case a 'line_name' is provided in the partition manifest, there would be two different entities in the code, which are referred by the same name: > - The IRQ handler function > - A macro which is substituted to the number of that IRQ line > > I'm not completely sure that it will not happen that the header file containing the macro gets included in a file that defines or declares the function which would break the privileged handler declaration or definition. Although I didn't check this situation occurs in the current implementation. > > Is my understanding correct? Is there a benefit of this proposal that I missed? > > Thanks, > Mate > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: 22 July 2019 17:23 > To: tf-m(a)lists.trustedfirmware.org; Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Subject: RE: including platform specific interrupt definitions > > After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: > > 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" > > 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" > > 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. > > I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': > > {% if handler.line_num %} > void irq_{{handler.line_num}}_Handler(void) > {% elif handler.line_name %} void {{handler.line_name}}_Handler(void) > > To this: > > {% if handler.line_name %} > void {{handler.line_name}}(void) > {% elif handler.line_num %} > void {{handler.line_num}}_Handler(void) > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Friday, July 19, 2019 1:36 PM > To: Mate Toth-Pal > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions > > Mate, > > Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. > > Thanks again, > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M > Sent: Friday, July 19, 2019 1:22 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions > > Hi Alan, > > I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ > This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. > > Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. > This replaces the manually created IPC model signal definitions to the generated signals: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ > > This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ > > This, and the related changes remove the manually created signal files. > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ > > So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. > > As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. > > Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. > > Regards, > Mate > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 19 July 2019 18:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] including platform specific interrupt definitions > > I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. > > What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Adrian Shaw

Just as a heads up for future consideration. In the final version of the PSA-FF spec we replaced the `line_num` and `line_name` attributes with a new single attribute called “source”. You can use numbers or string identifiers with it (see change log in Appendix E of PSA-FF 1.0.0). Best, Adrian > On 29 Jul 2019, at 15:37, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > When I created the templates, I was thinking that it is a good idea to have the '_Handler' postfix on the privileged interrupt handler names in both cases (e.g. 'line_num' or 'line_name' is provided.). This would keep the names aligned to the current pattern applied in the existing platform implementations. > > If I understand your proposal correctly, that means, in case a 'line_name' is provided in the partition manifest, there would be two different entities in the code, which are referred by the same name: > - The IRQ handler function > - A macro which is substituted to the number of that IRQ line > > I'm not completely sure that it will not happen that the header file containing the macro gets included in a file that defines or declares the function which would break the privileged handler declaration or definition. Although I didn't check this situation occurs in the current implementation. > > Is my understanding correct? Is there a benefit of this proposal that I missed? > > Thanks, > Mate > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: 22 July 2019 17:23 > To: tf-m(a)lists.trustedfirmware.org; Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Subject: RE: including platform specific interrupt definitions > > After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: > > 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" > > 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" > > 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. > > I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': > > {% if handler.line_num %} > void irq_{{handler.line_num}}_Handler(void) > {% elif handler.line_name %} void {{handler.line_name}}_Handler(void) > > To this: > > {% if handler.line_name %} > void {{handler.line_name}}(void) > {% elif handler.line_num %} > void {{handler.line_num}}_Handler(void) > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Friday, July 19, 2019 1:36 PM > To: Mate Toth-Pal > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions > > Mate, > > Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. > > Thanks again, > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M > Sent: Friday, July 19, 2019 1:22 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions > > Hi Alan, > > I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ > This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. > > Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. > This replaces the manually created IPC model signal definitions to the generated signals: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ > > This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ > > This, and the related changes remove the manually created signal files. > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ > > So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. > > As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. > > Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. > > Regards, > Mate > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 19 July 2019 18:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] including platform specific interrupt definitions > > I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. > > What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': {% if handler.line_num %} void irq_{{handler.line_num}}_Handler(void) {% elif handler.line_name %} void {{handler.line_name}}_Handler(void) To this: {% if handler.line_name %} void {{handler.line_name}}(void) {% elif handler.line_num %} void {{handler.line_num}}_Handler(void) Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Friday, July 19, 2019 1:36 PM To: Mate Toth-Pal Cc: tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Mate, Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. Thanks again, Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, July 19, 2019 1:22 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Last call for reviewing multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, I'm going to merge the multi-core topology improvement patches on feature-twincpu branch on Thursday. Could you please help review the following patches from https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 to https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/2? Please let me know if there is any issue or improper modification to single Armv8-M scenario. I'd like to fix conflict as much as possible before merging feature-twincpu back to master branch, which may bring a lot of inconvenience to master branch development. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, July 22, 2019 6:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: Hao Chuan Chu <charley.chu(a)cypress.com>; nd <nd(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; Alamy Liu <Alamy.Liu(a)cypress.com> Subject: [TF-M] Please review multi-core TF-M topology improvement patches Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Adding a platform specific tfm_svc_number_t

by Ken Liu (Arm Technology China)

Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC enumerations to > the tfm_svc_number_t typedef in tfm_svc.h as well as platform specific 'case's > to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
2
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

I found four additional code points in tfm_svcalls.c that needed to be enhanced to handle msg.type >= PSA_IPC_CALL. 3 of the four were like this: if (msg->msg.type != PSA_IPC_CALL) { Which I changed to: if (msg->msg.type < PSA_IPC_CALL) { The 4th occurrence was in the switch statement within 'tfm_svcall_psa_reply()'. I moved the 'case PSA_IPC_CALL:' logic into the default block and surrounded it with: if (msg->msg.type >= PSA_IPC_CALL) { ... } else { tfm_panic(); } With these changes in place, the new psa_call() 'type' argument appears to make its way peacefully and effectively through the plumbing. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Friday, July 26, 2019 2:28 PM To: Ken Liu (Arm Technology China) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr); Should be: msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr); Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. Alan From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment Summer-ARM closed this task as "Resolved". TASK DETAIL https://developer.trustedfirmware.org/T435 EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/ To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

I found several other code points in tfm_svcalls.c that need to be enhanced to handle 'type' >= PSA_IPC_CALL. Attached is my modified tfm_svcalls.c file. With these modifications, the 'type' argument makes its way through the system without causing tfm_panic() to be invoked. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Friday, July 26, 2019 2:28 PM To: Ken Liu (Arm Technology China) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr); Should be: msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr); Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. Alan From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment Summer-ARM closed this task as "Resolved". TASK DETAIL https://developer.trustedfirmware.org/T435 EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/ To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr); Should be: msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr); Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. Alan From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment Summer-ARM closed this task as "Resolved". TASK DETAIL https://developer.trustedfirmware.org/T435 EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/ To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit

6 years, 3 months

1
0
0 0

[RFC] Remove Isolation level 3

by Edison Ai (Arm Technology China)

Hi, There are a series of patches under "remove_isolation_level_3" topic: https://review.trustedfirmware.org/#/q/topic:remove_isolation_level_3+(stat… aim to remove isolation level 3 (TFM_LVL=3) from the library model. These patches will not affect curent isolation level 1 and level 2 for both library model and IPC model. Please help to review them and give comments if you find any problems or anywhere need to enhancement. Thanks, Edison

6 years, 3 months

1
0
0 0

Re: [TF-M] Adding a platform specific tfm_svc_number_t

by Andrej Butok

Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, July 26, 2019 3:49 AM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC > enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as > platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C42c1df29f3b84ac62f5708d7116b749e%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636997025530401902&sdata=vO0tq34jt > zFFn9D3cnrDP3a4fnrkq4h5jvzZmob2HnU%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 3 months

1
0
0 0

Adding a platform specific tfm_svc_number_t

by DeMars, Alan

I need to define platform specific SPM APIs that will be invoked by our SPs. Is there a convention for 'cleanly' adding platform specific SVC enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? Alan

6 years, 3 months

1
0
0 0

Uniform Secure Service Signature

by DeMars, Alan

With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan

6 years, 3 months

1
0
0 0

Re: [TF-M] PSA API prototype update

by DeMars, Alan

When do you anticipate that this patch will be merged to master? -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, July 23, 2019 11:17 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] PSA API prototype update Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
3
0 0

PSA API prototype update

by Ken Liu (Arm Technology China)

Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken

6 years, 3 months

1
0
0 0

TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, As you may be aware, implementing the PSA Internal Trusted Storage (ITS) APIs is on the TF-M roadmap for this quarter (https://developer.trustedfirmware.org/w/tf_m/planning/). We plan to implement these APIs with a new TF-M Internal Trusted Storage service. The design proposal for the new TF-M ITS service is now available for design review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 . The design is currently in "draft" state, which means further refinements are to be expected, and feedback is welcome. For more information about the PSA ITS APIs themselves, the PSA Storage API document may be downloaded from here: https://pages.arm.com/PSA-APIs Kind regards, Jamie

6 years, 3 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations * If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. * If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 1. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The hotfix has been merged. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, July 22, 2019 4:37 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Hotfix for auto-merge caused build error > > Hi, > The gerrit merge with auto rebase on this patch caused the function type change > and a build error is generated: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 > > A hotfix is on the way for fixing this: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 > > Sorry for the troublesome. > > /Ken > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The gerrit merge with auto rebase on this patch caused the function type change and a build error is generated: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 A hotfix is on the way for fixing this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 Sorry for the troublesome. /Ken

6 years, 3 months

1
0
0 0

Please help review memory access check design for multi-core topology

by David Hu (Arm Technology China)

Hi all, Could you please help review the design of TF-M memory access check in multi-core topology on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1601 ? Since CMSE support is likely to be unavailable on multi-core platforms, that design proposes a general memory access check process for multi-core topology and corresponding HAL APIs to retrieve platform specific memory attribute configurations. Any comment would be gratefully received. If this design may not work in certain use cases, it would be very helpful if you can let me know the details. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

Mate, Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. Thanks again, Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, July 19, 2019 1:22 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

including platform specific interrupt definitions

by DeMars, Alan

I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan

6 years, 3 months

1
0
0 0

Re: [TF-M] Missing veneer function implementations

by Kevin Townsend

Hi Mate, I was able to get this working by changing the build config to a non-IPC setup (ConfigDefault.cmake), in which case the tfm veneers functions are available and I can call the PSA API shims directly: SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_tfm_crypto_generate_random_veneer 100efc88 g F *ABS* 00000008 tfm_tfm_crypto_get_generator_capacity_veneer ... Thanks for the clarification. Calling `psa_generate_random` from the NSPE works are expected now. Best regards, Kevin On Wed, 17 Jul 2019 at 14:16, Mate Toth-Pal via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Kevin, > > Based on what you write your build is probably OK. To access the > psa_generate_random service, you need to call the function 'psa_status_t > psa_generate_random(uint8_t *output, size_t output_size)', declared in > interface/include/psa/crypto.h. > > in case the TFM/PSA APIs are in use (your case), the transition to the > secure code is done through the tfm_psa_* veneers. A service (for example > psa_generate_random) is connected with a call to 'psa_connect(...)', which > is provided with the ID of the selected service, and then 'psa_call(...)' > is called with the handle received from 'psa_connect(...)' (as it is > described in the PSA FF Specification). However this exchange is > implemented inside the TF-M's crypto API implementation in > interface\src\tfm_crypto_api.c, so you only need to call the API function. > > The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M > when the Library model is used. In this case the secure services can be > accessed with a single function call, and the tfm_psa_* veneers are not > available. However please note, that even in this case you can use TF-M's > crypto API, which will call the service the correct way. (Look for the > conditionally compiled blocks depending on the TFM_PSA_API macro in the API > implementation.) > > I hope this answers your questions. > > Regards, > Mate > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > Sent: 17 July 2019 13:12 > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Missing veneer function implementations > > Greetings, > > I'm trying to get the TFM/PSA APIs working in Zephyr, based on the > upstream TF-M repository. > > The libraries are being built with the following settings, followed by > make and make install: > > cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f > ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > *ConfigRegressionIPC is used simply to include the test service for > debugging purposes for now. > > The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making > calls to the SPE via the PSA APIs, which should call the appropriate > veneers via the source files in the `install/export/tfm` folder, as well as > `veneers/s_veneers.o` > > This works fine calling the test service via `tfm_psa_call_veneer`, but > whenever I try to make use of any of the .c shims in the PSA API (for > example `psa_generate_random`), I get the following error(s): > > tfm_crypto_api.c:1571: undefined reference to > `tfm_tfm_crypto_generate_random_veneer' > > I assumed the veneers are in the `s_veneers.o` file generated as part of > the TF-M build, and this file is linked into during the Zephyr build > process, but when I look at the contents of the .o file (which was > suspiciously small at 740b) I only see the following: > > $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o > > /tfm/build/install/export/tfm/veneers/s_veneers.o: file format > elf32-littlearm > > SYMBOL TABLE: > 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer > 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S > 100efc90 g F *ABS* 00000008 TZ_LoadContext_S > > 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer > 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer > 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S > 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer > 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S > 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests > 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S > 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer > 100efcd8 g F *ABS* 00000008 tfm_register_client_id > > Clearly I'm missing something in the build process so that all of the > other veneers are present, but it's not obvious to me at this point what. > At present I can only make calls to `tfm_psa_call` to the test service, but > that isn't going to help with the goal of publishing a sample application > that meets the requirements for PSA Level 1 certification. > > Any suggestions on what knob to turn to include the missing veneers would > be very welcome. > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 3 months

2
1
0 0

Re: [TF-M] Missing veneer function implementations

by Mate Toth-Pal

Hi Kevin, Based on what you write your build is probably OK. To access the psa_generate_random service, you need to call the function 'psa_status_t psa_generate_random(uint8_t *output, size_t output_size)', declared in interface/include/psa/crypto.h. in case the TFM/PSA APIs are in use (your case), the transition to the secure code is done through the tfm_psa_* veneers. A service (for example psa_generate_random) is connected with a call to 'psa_connect(...)', which is provided with the ID of the selected service, and then 'psa_call(...)' is called with the handle received from 'psa_connect(...)' (as it is described in the PSA FF Specification). However this exchange is implemented inside the TF-M's crypto API implementation in interface\src\tfm_crypto_api.c, so you only need to call the API function. The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M when the Library model is used. In this case the secure services can be accessed with a single function call, and the tfm_psa_* veneers are not available. However please note, that even in this case you can use TF-M's crypto API, which will call the service the correct way. (Look for the conditionally compiled blocks depending on the TFM_PSA_API macro in the API implementation.) I hope this answers your questions. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 17 July 2019 13:12 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Missing veneer function implementations Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

MCUBoot enhancments

by Tamas Ban

Hi All, I've pushed a set of patches for review which aims to add the following features to MCUBoot: * Integration with HW key(s). * Sign & authenticate S and NS image independently with different keys. Design proposal for this change: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Related changes are listed here: https://developer.trustedfirmware.org/T438 Please feel free to review any of the patches.:) Thanks, Tamas

6 years, 3 months

1
0
0 0

Missing veneer function implementations

by Kevin Townsend

Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend

6 years, 3 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > TF-M Crypto will align to newest release of Mbed Crypto when they will become available Just FYI: The newest official release of Mbed Crypto is v1.1.0: https://github.com/ARMmbed/mbed-crypto/releases Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 3 months

2
2
0 0

Changing IPC design document to .rst format

by Ken Liu (Arm Technology China)

Hi, This is a design document change for IPC, the intention is to change design document from wiki page to rst format. The patch is put at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1533 The plan is to put this design document under source control and the following feature changes and enhancement about IPC will be pushed as patches on it - which helps review. Since the original text is already public so I changed the doc status to 'Detailed', plan is to merge it soon with some quick comment. If you think some necessary points are missing please leave comments in this mailing thread and we will add them later with a new patch. Thanks. -Ken

6 years, 3 months

1
0
0 0

Re: [TF-M] Common scatter files and templates

by David Hu (Arm Technology China)

Hi Andrej, Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, July 11, 2019 7:41 PM To: Ken Liu (Arm Technology China) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Common scatter files and templates Hi Ken, > Could you help to tell the name of the file you don't want to be removed? So, any .c,.h,.inc and linker file which may be used during compilation. An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files. Thanks, Andrej -----Original Message----- From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Sent: Thursday, July 11, 2019 12:44 PM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Common scatter files and templates Hi Andrej, Could you help to tell the name of the file you don't want to be removed? So that we can estimate what is important for IDE projects and how we could help on that. An introduction of how your IDE integrate with TF-M code is also welcome. Would you share this to us? Thanks. -Ken > -----Original Message----- > From: Andrej Butok <andrey.butok(a)nxp.com> > Sent: Thursday, July 11, 2019 2:25 PM > To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De > Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: RE: Common scatter files and templates > > Pre-generated files are required for TFM IDE projects. > Please do not delete them, find other solution! > It can be solved by adding #if/#ifdef. > > Thank you, > Andrej Butok > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Hu (Arm Technology China) via TF-M > Sent: Thursday, July 11, 2019 4:08 AM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf- > m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Common scatter files and templates > > Hi Antonio, Ken, Miklos, > > Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to > comment the veneer sections in the templates in multi-core topology. > Each time before building, we have to run the Python script to > generate new link script/scatter file with veneer disabled, to replace the existing ones. > It becomes more inconvenient as the number of developers and users on > feature-twincpu branch grows. > > As Chris proposed on > https://review.tr > ustedfirmware.org%2Fc%2Ftrusted-firmware- > m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068 > 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS > Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to > directly update the "generated" linker script/scatter file as well, on > feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common > flag used in multi- core topology and will help resolve our urgent problem. > If the final improvement solution is completed on master branch, we > will update the feature branch accordingly when merging it back to master branch. > > Please let me know if there is a better option for feature-twincpu branch. > Thank you. > > Best regards, > Hu Ziji > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Thursday, July 11, 2019 3:53 AM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] Common scatter files and templates > > Hi Chris, > > you are right, that file is autogenerated from the template file but > both are kept under source control. The reason for this is that the > autogenerated file is not created at build time but by manually > running the tfm_parse_manifest_list.py, which has to be run every time > something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. > > On the other hand, the build system could be modified to run the > parsers at build time so that the autogenerated files wouldn't have to > be stored in source control, and we could keep only the template. > These two alternatives are both equally valid in my view, but if there > is strong consensus for the other we can discuss. > > Thanks, > Antonio > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 10 July 2019 19:50 > To: TF-M(a)lists.trustedfirmware.org; Miklos Balint > Subject: [TF-M] Common scatter files and templates > > Can somebody please help me understand this? > $ ls platform/ext/common/armclang/ > tfm_common_s.sct tfm_common_s.sct.template $ ls > platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In > both directories, both files are under source control, but the > non-template files say that they're auto-generated: > /*********** WARNING: This is an auto-generated file. Do not edit! > ***********/ > > It's unusual to see both the source file and the artifact under source control. > > It seems that they're generated by tools/tfm_parse_manifest_list.py, > but that doesn't seem to be run as part of the build, so when is it run? > > Thanks, > > Chris > > > This message and any attachments may contain confidential information > from Cypress or its subsidiaries. If it has been received in error, > please advise the sender and immediately delete this message. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
3
0 0

Re: [TF-M] Common scatter files and templates

by Thomas Törnblom

For clarification, the IAR IDE supports both pre and post build actions. /Thomas Den 2019-07-11 kl. 15:17, skrev David Hu (Arm Technology China) via TF-M: > Hi Andrej, > > > Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step? > > > Best regards, > > Hu Ziji > > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Thursday, July 11, 2019 7:41 PM > To: Ken Liu (Arm Technology China) > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Common scatter files and templates > > Hi Ken, > >> Could you help to tell the name of the file you don't want to be removed? > So, any .c,.h,.inc and linker file which may be used during compilation. > An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files. > > Thanks, > Andrej > > -----Original Message----- > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Sent: Thursday, July 11, 2019 12:44 PM > To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: Common scatter files and templates > > Hi Andrej, > > Could you help to tell the name of the file you don't want to be removed? > So that we can estimate what is important for IDE projects and how we could help on that. > > An introduction of how your IDE integrate with TF-M code is also welcome. > Would you share this to us? > > Thanks. > > -Ken > > >> -----Original Message----- >> From: Andrej Butok <andrey.butok(a)nxp.com> >> Sent: Thursday, July 11, 2019 2:25 PM >> To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De >> Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China) >> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org >> Subject: RE: Common scatter files and templates >> >> Pre-generated files are required for TFM IDE projects. >> Please do not delete them, find other solution! >> It can be solved by adding #if/#ifdef. >> >> Thank you, >> Andrej Butok >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David >> Hu (Arm Technology China) via TF-M >> Sent: Thursday, July 11, 2019 4:08 AM >> To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf- >> m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) >> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: Re: [TF-M] Common scatter files and templates >> >> Hi Antonio, Ken, Miklos, >> >> Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to >> comment the veneer sections in the templates in multi-core topology. >> Each time before building, we have to run the Python script to >> generate new link script/scatter file with veneer disabled, to replace the existing ones. >> It becomes more inconvenient as the number of developers and users on >> feature-twincpu branch grows. >> >> As Chris proposed on >> https://review.tr >> ustedfirmware.org%2Fc%2Ftrusted-firmware- >> m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068 >> 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635% >> 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS >> Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to >> directly update the "generated" linker script/scatter file as well, on >> feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common >> flag used in multi- core topology and will help resolve our urgent problem. >> If the final improvement solution is completed on master branch, we >> will update the feature branch accordingly when merging it back to master branch. >> >> Please let me know if there is a better option for feature-twincpu branch. >> Thank you. >> >> Best regards, >> Hu Ziji >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Antonio De Angelis via TF-M >> Sent: Thursday, July 11, 2019 3:53 AM >> To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [TF-M] Common scatter files and templates >> >> Hi Chris, >> >> you are right, that file is autogenerated from the template file but >> both are kept under source control. The reason for this is that the >> autogenerated file is not created at build time but by manually >> running the tfm_parse_manifest_list.py, which has to be run every time >> something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. >> >> On the other hand, the build system could be modified to run the >> parsers at build time so that the autogenerated files wouldn't have to >> be stored in source control, and we could keep only the template. >> These two alternatives are both equally valid in my view, but if there >> is strong consensus for the other we can discuss. >> >> Thanks, >> Antonio >> >> ________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of >> Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 10 July 2019 19:50 >> To: TF-M(a)lists.trustedfirmware.org; Miklos Balint >> Subject: [TF-M] Common scatter files and templates >> >> Can somebody please help me understand this? >> $ ls platform/ext/common/armclang/ >> tfm_common_s.sct tfm_common_s.sct.template $ ls >> platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In >> both directories, both files are under source control, but the >> non-template files say that they're auto-generated: >> /*********** WARNING: This is an auto-generated file. Do not edit! >> ***********/ >> >> It's unusual to see both the source file and the artifact under source control. >> >> It seems that they're generated by tools/tfm_parse_manifest_list.py, >> but that doesn't seem to be run as part of the build, so when is it run? >> >> Thanks, >> >> Chris >> >> >> This message and any attachments may contain confidential information >> from Cypress or its subsidiaries. If it has been received in error, >> please advise the sender and immediately delete this message. >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 3 months

1
0
0 0

Re: [TF-M] Common scatter files and templates

by Andrej Butok

Pre-generated files are required for TFM IDE projects. Please do not delete them, find other solution! It can be solved by adding #if/#ifdef. Thank you, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, July 11, 2019 4:08 AM To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Antonio, Ken, Miklos, Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones. It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows. As Chris proposed on https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem. If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch. Please let me know if there is a better option for feature-twincpu branch. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, July 11, 2019 3:53 AM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 3 months

2
2
0 0

Re: [TF-M] Common scatter files and templates

by David Hu (Arm Technology China)

Hi Antonio, Ken, Miklos, Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones. It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows. As Chris proposed on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1527, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem. If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch. Please let me know if there is a better option for feature-twincpu branch. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, July 11, 2019 3:53 AM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
2
0 0

Re: [TF-M] Common scatter files and templates

by Antonio De Angelis

Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Common scatter files and templates

by Christopher Brand

Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 3 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

How would a git repo with some submodules preclude any of the things you mentioned? I guess my initial thought is that there would be an “uber” repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. There’s also the option of using cmake ExternalProject (https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e…) Or west https://pypi.org/project/west/ - k > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed. > 'repo' was considered as well, but repo tool doesn't work on windows(last I checked). > > Thanks, > Ashu > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M > Sent: 10 July 2019 09:50 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Using git submodules for dependencies? > > There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. > > - k > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Kevin, >> >> Only if 100% of the external project source code is used without change. >> Even if it is valid now, nobody will give you this guarantee in future. >> >> Regards, >> Andrej >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M >> Sent: Wednesday, July 10, 2019 10:41 AM >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] Using git submodules for dependencies? >> >> Hi, >> >> I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. >> >> Was the idea of git submodules for dependencies considered and rejected? >> Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. >> >> There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? >> >> Best regards, >> Kevin Townsend >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Add multi-image support to MCUBoot

by David Vincze

Hi All, I've pushed a set of patches for review which aims to add multi-image support to MCUBoot. It enables the Secure and Non-secure images to be handled and updated separately by the bootloader. You can find the links of the reviews and more information in the following ticket: https://developer.trustedfirmware.org/T421 Please feel free to review any of the patches.:) Thanks, David

6 years, 3 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Ashutosh Singh

Hi, Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed. 'repo' was considered as well, but repo tool doesn't work on windows(last I checked). Thanks, Ashu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 10 July 2019 09:50 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies? There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. - k > On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Kevin, > > Only if 100% of the external project source code is used without change. > Even if it is valid now, nobody will give you this guarantee in future. > > Regards, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M > Sent: Wednesday, July 10, 2019 10:41 AM > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Using git submodules for dependencies? > > Hi, > > I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. > > Was the idea of git submodules for dependencies considered and rejected? > Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. > > There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. - k > On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Kevin, > > Only if 100% of the external project source code is used without change. > Even if it is valid now, nobody will give you this guarantee in future. > > Regards, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M > Sent: Wednesday, July 10, 2019 10:41 AM > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Using git submodules for dependencies? > > Hi, > > I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. > > Was the idea of git submodules for dependencies considered and rejected? > Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. > > There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Andrej Butok

Hi Kevin, Only if 100% of the external project source code is used without change. Even if it is valid now, nobody will give you this guarantee in future. Regards, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, July 10, 2019 10:41 AM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Using git submodules for dependencies? Hi, I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 3 months

1
0
0 0

Using git submodules for dependencies?

by Kevin Townsend

Hi, I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? Best regards, Kevin Townsend

6 years, 3 months

1
0
0 0

Re: [TF-M] [PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, The last patch for this task is pushed for review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1487 Please help to review and the 'configs' directory would be the only place for holding configurations. Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 25, 2019 2:02 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [PLEASE READ] Move configuration files into specified directory > > Hi, > Configurations has been moved into 'configs' directory. Please: > - Update your build commands to build with configurations under 'configs' > directory, check updated document: docs/user_guides/tfm_build_instruction.rst > - If you want to push new configurations, please put new configurations under > 'configs' directory. > > The dummy configurations under root directory will be removed soon so please > DO UPDATE YOUR BUILD COMMAND! > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 18, 2019 10:03 AM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > The patch has been pushed for a while and is going to be merged in one > > week, please help to review it if you planned but still not have a look: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > After this patch get merged, all new configurations created in root > > directory will be rejected. Please create new configuration files under ./configs > directory. > > The existing fake configuration files under root directory will be > > removed after CI setting changed. > > > > Thanks. > > > > -Ken > > > > > -----Original Message----- > > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > > Liu (Arm Technology China) via TF-M > > > Sent: Tuesday, June 11, 2019 1:40 PM > > > To: TF-M(a)lists.trustedfirmware.org > > > Cc: nd <nd(a)arm.com> > > > Subject: [TF-M] [RFC] Move configuration files into specified > > > directory > > > > > > Hi, > > > Since the number of configuration files is increasing, let’s move > > > the configuration files (ConfigXXXX.cmake) into specified directory. > > > This would reduces the files under root directory and makes the > > > structure more clearer. > > > > > > I have created the issue and patch for it: > > > https://developer.trustedfirmware.org/T394 > > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > > > IMPORTANT NOTES: > > > To be compatible with the existing building configurations, the > > > existing configuration files have been forwarded into the > > > corresponded configuration file under ./configs. Which means there > > > are two set of configuration files under sources tree at current – > > > but this will change soon. There is a warning while you are building > > > with root configurations files: “Please use the configs available in > > > the ./config sub- > > directory.” > > > > > > So please: > > > > > > - If you are planning to create new configuration, create it under > > > ./configs instead of root directory > > > - The reference of configuration files under root directory will be > > > removed soon, please change your build system setting to reference > > > the configuration files put under ./configs > > > > > > Any feedbacks please reply this mail or put comments under the > > > issue, thanks > > > 😉 > > > > > > -Ken > > > > > > -- > > > TF-M mailing list > > > TF-M(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

independent device driver model working along side SPM

by R, Manoj

Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj

6 years, 3 months

1
0
0 0

Changes to PSA headers in TF-M

by Jamie Fox

Hi all, I am proposing a couple of changes to the standard PSA headers in TF-M. The first change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1458/ It renames the standard PSA headers in TF-M from psa_<api>.h to psa/<api>.h. TF-M defined headers are not affected. This change also tweaks a large number of #includes across the TF-M repo to use the new names. Any code maintained outside the TF-M repo that includes PSA headers from TF-M will also need to be changed to use the new names in #includes once this is merged. The benefit of this change is that is brings the names of the headers in TF-M into agreement with the names used in the PSA Firmware Framework. It will also make running the PSA API tests easier, as the step of copying the PSA headers to the standard names is no longer required. The second change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1459/ It adds a copy of the psa/error.h header, which contains new standard error codes intended to be used by the SPM and RoT Services. The "PSA_SUCCESS" and "psa_status_t" definitions are also moved to this header, and it is included by psa/client.h and psa/service.h. This change should have minimal impact on other code -- no code is immediately changed to use the new error codes, but upstreaming the header now allows services to start using the new error codes when needed. Kind regards, Jamie

6 years, 4 months

1
0
0 0

[RFC] Secure Partition Runtime Library

by Ken Liu (Arm Technology China)

Hi, We are now involving secure partition runtime library into tf-m design. While implementing isolation level 2, some runtime APIs (printf e.g.) calling would cause fault, because it is accessing global variables (The STDIO instance) or need to manipulate hardware (UART). So we shutdown calling to these APIs - it is lucky that the secure service logic does not rely on these functions. This leads to the thinking of runtime APIs implementation - not only C runtime mentioned in PSA FF specification, but also developer APIs for service client. These APIs are definitely necessary and need to work well under all isolation levels. Since we cannot put multiple runtime copies into secure partitions (waste and not supported by single firmware linker design), shared runtime library looks like the only choice. Here we introduce the design of a runtime library for secure partition usage. We aligned the concepts with PSA FF and it does not break the mandatory requirements of isolation, and proposes designs for some dedicated APIs. I know there may be similar runtime implementations somewhere, while I just want to implement the functions quick to make out a solution before other library searching and investigating stage (which may spent quite much time). The key requirements of this runtime library are: - This library is protected as Read-Only + executable by MPU, so all other data will not be included into protected region. This point is very important. - For those session/handle based API set, necessary supporting from tooling or other parts needs to be involved. Please help to review the design document at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1425 Feel free to add you as reviewers and comment something; and you can reply to this thread, too. Any new thinking is worthy of being discussed. Thanks. -Ken

6 years, 4 months

1
0
0 0

Attestation token verifier

by Tamas Ban

Hi, You can find here a useful script which can be used to verify an initial attestation token(IAT) on server side when it is retrieved from the IoT device: https://developer.trustedfirmware.org/T411 BR, Tamas

6 years, 4 months

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Andrej Butok

Hi Antonio, Sorry, ignore the previous e-mail. Yes, tfm_mbedcrypto_include.h was mixed up with tfm_mbedcrypto_config.h -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, June 27, 2019 12:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] tfm_mbedcrypto_include.h Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Antonio De Angelis

Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

tfm_mbedcrypto_include.h

by Andrej Butok

Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

6 years, 4 months

1
0
0 0

Experimental IAR support

by Thomas Törnblom

Thank you for merging my cleanup in T398. I have a set of IAR build related files that I would like to push, both new and modified cmake files and startup and linker scripts for the Musca A board. There is still some work needed on the linker scripts to get everything fully functional but I can load and debug the secure and non secure images, and the non-secure image will start and execute the idle thread. I have not tested mcuboot although it appears to build properly. We have chip vendors that are eagerly awaiting our port and I would like to push this as "experimental". Would this be OK? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 4 months

1
0
0 0

Re: [TF-M] Feature request

by Gyorgy Szing

Hi Andrej, We shall avoid adding IDE specific workarounds to the code. I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.…) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint <Miklos.Balint(a)arm.com>; Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Feature request Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

2
2
0 0

[PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, Configurations has been moved into 'configs' directory. Please: - Update your build commands to build with configurations under 'configs' directory, check updated document: docs/user_guides/tfm_build_instruction.rst - If you want to push new configurations, please put new configurations under 'configs' directory. The dummy configurations under root directory will be removed soon so please DO UPDATE YOUR BUILD COMMAND! Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 18, 2019 10:03 AM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Move configuration files into specified directory > > Hi, > The patch has been pushed for a while and is going to be merged in one week, > please help to review it if you planned but still not have a look: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > After this patch get merged, all new configurations created in root directory will > be rejected. Please create new configuration files under ./configs directory. > The existing fake configuration files under root directory will be removed after > CI setting changed. > > Thanks. > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 11, 2019 1:40 PM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > Since the number of configuration files is increasing, let’s move the > > configuration files (ConfigXXXX.cmake) into specified directory. > > This would reduces the files under root directory and makes the > > structure more clearer. > > > > I have created the issue and patch for it: > > https://developer.trustedfirmware.org/T394 > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > IMPORTANT NOTES: > > To be compatible with the existing building configurations, the > > existing configuration files have been forwarded into the corresponded > > configuration file under ./configs. Which means there are two set of > > configuration files under sources tree at current – but this will > > change soon. There is a warning while you are building with root > > configurations files: “Please use the configs available in the ./config sub- > directory.” > > > > So please: > > > > - If you are planning to create new configuration, create it under > > ./configs instead of root directory > > - The reference of configuration files under root directory will be > > removed soon, please change your build system setting to reference the > > configuration files put under ./configs > > > > Any feedbacks please reply this mail or put comments under the issue, > > thanks > > 😉 > > > > -Ken > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

TF-M CI Blog

by Shebu Varghese Kuriakose

Hi All, Not sure if everyone knows that there is an initial deployment of TF-M CI (Continuous Integration) system. It tests every patch that gets submitted in TF-M gerrit. Read about the CI system and find the relevant links in this blog - https://www.trustedfirmware.org/blog/trusted-firmware-open-ci-update/ Thanks, Shebu

6 years, 4 months

1
0
0 0

Please help review the patches of architecture abstraction in TF-M

by David Hu (Arm Technology China)

Hi all, Could you please review the following patches to abstract architecture specific code? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157/<https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1158 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1390/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1251/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1252/ The above patches abstract architecture specific code to decouple TF-M core to specific architecture details. It can help enable TF-M running on diverse Arm M-profile architectures. Other Arm M-profile architecture implementation will be added later. Suggestions are welcome. Thank you. Best regards, Hu Ziji

6 years, 4 months

1
0
0 0

Align manifest to PSA FF

by Edison Ai (Arm Technology China)

Hi, I had create patches related to manifest. There are two topics for it: * Align manifest to PSA FF: https://review.trustedfirmware.org/#/q/topic:Align_manifest_to_PSA_FF+(stat… * Generate SID and signal header files according to manifest: https://review.trustedfirmware.org/#/q/topic:generate_SID_signal_header_fil… I had added some reviewers to help to review them. Please feel free to give any comment even you are not in reviewer list(Sorry maybe skip someone by mistake). There are some important patches I think and please pay your attention to them: * Remove "tfm_symbol" from manifest: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1243/ * Change the value of SID: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1246/ * Rename the manifest file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1247/ * Generate manifest file name header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ * Assign signal value to SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ * Generate service ID header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1353/ Thanks, Edison

6 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Christian Daudt

If the objective of assigning it to TEST_PASSED before the test is that it becomes the default final answer (i.e. unless it gets reassigned to TEST_FAILED the final result remains this assignment) then it should absolutely be set to TEST_PASSED at startup. thanks, Christian. ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 19, 2019 6:00 AM To: Thomas Törnblom; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Jamie Fox

Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Thomas Törnblom

I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Just FYI The problem has been solved. The main issue was caused by not correct integration of mbedCrypto on our side. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, June 14, 2019 5:12 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Is TFM_PSA_API broken? Just FYI: Downgraded to commit SHA-1: 25e2b2dba5d7eb3ba0da14384a6c8240278f5c15 (Crypto: Implement additional PSA Crypto APIs). It becomes much better, but finally goes to the assert in some time (tfm_thrd_context_switch:170). Will continue next week. The terminal log: Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' TEST PASSED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' TEST PASSED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2004' Description: 'Set interface with invalid data length' TEST PASSED! > Executing 'TFM_SST_TEST_2005' Description: 'Set interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2006' Description: 'Get interface with valid data' TEST PASSED! > Executing 'TFM_SST_TEST_2007' Description: 'Get interface with zero data length' TEST PASSED! > Executing 'TFM_SST_TEST_2008' Description: 'Get interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2009' Description: 'Get interface with invalid data lengths and offsets' TEST PASSED! > Executing 'TFM_SST_TEST_2010' Description: 'Get interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2011' Description: 'Get info interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2012' Description: 'Get info interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2013' Description: 'Get info interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2014' Description: 'Get info interface with NULL info pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2015' Description: 'Remove interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2016' Description: 'Remove interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2017' Description: 'Remove interface with invalid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2018' Description: 'Block compaction after remove' TEST PASSED! > Executing 'TFM_SST_TEST_2019' Description: 'Multiple partial gets' TEST PASSED! > Executing 'TFM_SST_TEST_2020' Description: 'Multiple sets to same UID from same thread' TEST PASSED! > Executing 'TFM_SST_TEST_2021' Description: 'Get support interface' TEST PASSED! TESTSUITE PASSED! Running Test Suite SST reliability tests (TFM_SST_TEST_3XXX)... > Executing 'TFM_SST_TEST_3001' Description: 'repetitive sets and gets in/from an asset' > Iteration 15 of 15 TEST PASSED! > Executing 'TFM_SST_TEST_3002' Description: 'repetitive sets, gets and removes' > Iteration 15 of 15 TEST PASSED! TESTSUITE PASSED! Running Test Suite Crypto secure interface tests (TFM_CRYPTO_TEST_5XXX)... > Executing 'TFM_CRYPTO_TEST_5001' Description: 'Secure Key management interface' Assert:tfm_thrd_context_switch:170 From: Andrej Butok Sent: Friday, June 14, 2019 4:14 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, > Please check your modification in SST partition No modifications from my side. As it becomes wasting of time, a debugging is not consistent and looks like uninitialized variable, stack or something else. I have decided to find a TFM commit which caused this abnormal behavior. So far, it occurs in a commit between: NOT WORKING: SHA-1: 122360ffb1e7278406183714249afefcb2184488 * Attest: Replace example asymmetric key-pair WORKING: SHA-1: 4743e6731b0fe8a00ceebfd74da098c7676ac6e0 * Crypto: Add IPC compatibility Thanks, Andrej From: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Sent: Friday, June 14, 2019 4:00 PM To: Andrej Butok <mailto:andrey.butok@nxp.com> Cc: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: Re: Is TFM_PSA_API broken? Hi Andrej, As I said, that workaround only works for specified case. Debugging these failed cases with this patch applied will lead you into heavy core debugging. We need to find out the root cause, why the assert is triggered? There is no reason that all partitions go into block state, unless there are some improper modification in core or secure partitions. Please check your modification in SST partition, try to print something in your SST thread, to see why the thread keeps in block state. If a client calls psa_connect/psa_all, SPM would activate the partition into running state with function tfm_spm_send_event(). The correct call routine should be (psa_call has the similar routine): tfm_sst_test_2001->psa_connect->...->SVC_Handler->tfm_svcall_psa_connect->tfm_spm_send_event->....-> (your partition thread). Please remove the workaround patch, and try to debug to see if the call routine is correct. Thanks. -Ken ________________________________________ From: Andrej Butok <mailto:andrey.butok@nxp.com> Sent: Friday, June 14, 2019 8:13 PM To: Ken Liu (Arm Technology China) Cc: mailto:tf-m@lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: mailto:TF-M@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <mailto:Antonio.DeAngelis@arm.com> > Cc: mailto:tf-m@lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: mailto:tf-m@lists.trustedfirmware.org > Cc: nd <mailto:nd@arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M > <mailto:tf-m-bounces@lists.trustedfirmware.org%3cmailto:tf-m-%0b> > mailto:bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok > via TF-M > > Sent: 13 June 2019 15:46 > > To: > mailto:tf-m@lists.trustedfirmware.org%3cmailto:tf-m@lists.trustedfirmw > are.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > mailto:TF-M@lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%3D&reserved=0 -- TF-M mailing list mailto:TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

1
0
0 0

Re: [TF-M] Supported versions of the Armclang compiler in the TF-M build

by Antonio De Angelis

Hi all, As I haven't received any objection to the below, I am going to merge the change which drops support for Armclang 6.7 and Armclang 6.9. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 06 June 2019 11:28 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Supported versions of the Armclang compiler in the TF-M build Dear all, We are considering to drop support for older versions of the Armclang compiler (i.e. 6.7 and 6.9) to focus support on newer releases (thus increasing the requirement on Armclang version to 6.10 or higher). https://developer.trustedfirmware.org/T392 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223 If you have any specific requirement to use Armclang 6.7 or 6.9, please get in touch here or on the review. Thanks, Antonio -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Feature request

by Andrej Butok

Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Cooperative Scheduler Design - Scheduling Rules

by Ken Liu (Arm Technology China)

Hi Ashu, The proposal is good and covers most of the cases while a NS and S communication channel is available. And I think below part is going to be considerate before we create design docs to follow this rules: - Leave the NSPE SPM_IDLE case handling as implementation defined instead of involving IRQ to bring more complexity. NSPE could just yield but SPE needs to support a bit asynchronization -- that is not a big fair compare to IRQ communication. - The rules rely on the NSPE/SPE communication channel but for if NSPE has no use/misuse this channel SPE should detect the problem and panic NSPE, this is also can to be implemented. Most of the interrupt priority related rules can be done with hardware setting. The priority of secure partition with IRQ needs to be considerate while partitions designing since in IPC model scheduler decides who should go based on partition priority. Let's see if we can find more cases while implementing. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ashutosh > Singh via TF-M > Sent: Tuesday, April 30, 2019 7:06 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] TF-M Cooperative Scheduler Design - Scheduling Rules > > Hi, > > This is a proposal that introduces scheduling rules in TF-M. > Introduction: > On ArmV8-M CPUs, NSPE and SPE share the same physical processing > element(PE). A TF-M enabled system need to be able to handle asynchronous > events (interrupts) regardless of current security state of the PE; and that may > lead to scheduling decisions. This introduces significant complexity into TF-M. To > keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and > SPE, following set of rules are imposed on the TF-M scheduler design. > https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/ > > Feedback welcome! > > Thanks, > Ashu > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] [RFC] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, The patch has been pushed for a while and is going to be merged in one week, please help to review it if you planned but still not have a look: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 After this patch get merged, all new configurations created in root directory will be rejected. Please create new configuration files under ./configs directory. The existing fake configuration files under root directory will be removed after CI setting changed. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 11, 2019 1:40 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [RFC] Move configuration files into specified directory > > Hi, > Since the number of configuration files is increasing, let’s move the > configuration files (ConfigXXXX.cmake) into specified directory. > This would reduces the files under root directory and makes the structure more > clearer. > > I have created the issue and patch for it: > https://developer.trustedfirmware.org/T394 > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > IMPORTANT NOTES: > To be compatible with the existing building configurations, the existing > configuration files have been forwarded into the corresponded configuration > file under ./configs. Which means there are two set of configuration files under > sources tree at current – but this will change soon. There is a warning while you > are building with root configurations files: “Please use the configs available in > the ./config sub-directory.” > > So please: > > - If you are planning to create new configuration, create it under ./configs > instead of root directory > - The reference of configuration files under root directory will be removed soon, > please change your build system setting to reference the configuration files put > under ./configs > > Any feedbacks please reply this mail or put comments under the issue, thanks > 😉 > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Feature request

by Miklos Balint

Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Antonio De Angelis

Hi Andrej, Does this affect also any of the reference platforms (i.e. AN521)? If the same behaviour appears on a reference platform, it will suggest that is likely not related to platform code. It would be good if you can identify the EXACT commit that is giving you this problem, as we can't reproduce, so that we can have a look in detail to the source code. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 14 June 2019 16:12 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Is TFM_PSA_API broken? Just FYI: Downgraded to commit SHA-1: 25e2b2dba5d7eb3ba0da14384a6c8240278f5c15 (Crypto: Implement additional PSA Crypto APIs). It becomes much better, but finally goes to the assert in some time (tfm_thrd_context_switch:170). Will continue next week. The terminal log: Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' TEST PASSED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' TEST PASSED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2004' Description: 'Set interface with invalid data length' TEST PASSED! > Executing 'TFM_SST_TEST_2005' Description: 'Set interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2006' Description: 'Get interface with valid data' TEST PASSED! > Executing 'TFM_SST_TEST_2007' Description: 'Get interface with zero data length' TEST PASSED! > Executing 'TFM_SST_TEST_2008' Description: 'Get interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2009' Description: 'Get interface with invalid data lengths and offsets' TEST PASSED! > Executing 'TFM_SST_TEST_2010' Description: 'Get interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2011' Description: 'Get info interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2012' Description: 'Get info interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2013' Description: 'Get info interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2014' Description: 'Get info interface with NULL info pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2015' Description: 'Remove interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2016' Description: 'Remove interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2017' Description: 'Remove interface with invalid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2018' Description: 'Block compaction after remove' TEST PASSED! > Executing 'TFM_SST_TEST_2019' Description: 'Multiple partial gets' TEST PASSED! > Executing 'TFM_SST_TEST_2020' Description: 'Multiple sets to same UID from same thread' TEST PASSED! > Executing 'TFM_SST_TEST_2021' Description: 'Get support interface' TEST PASSED! TESTSUITE PASSED! Running Test Suite SST reliability tests (TFM_SST_TEST_3XXX)... > Executing 'TFM_SST_TEST_3001' Description: 'repetitive sets and gets in/from an asset' > Iteration 15 of 15 TEST PASSED! > Executing 'TFM_SST_TEST_3002' Description: 'repetitive sets, gets and removes' > Iteration 15 of 15 TEST PASSED! TESTSUITE PASSED! Running Test Suite Crypto secure interface tests (TFM_CRYPTO_TEST_5XXX)... > Executing 'TFM_CRYPTO_TEST_5001' Description: 'Secure Key management interface' Assert:tfm_thrd_context_switch:170 From: Andrej Butok Sent: Friday, June 14, 2019 4:14 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, > Please check your modification in SST partition No modifications from my side. As it becomes wasting of time, a debugging is not consistent and looks like uninitialized variable, stack or something else. I have decided to find a TFM commit which caused this abnormal behavior. So far, it occurs in a commit between: NOT WORKING: SHA-1: 122360ffb1e7278406183714249afefcb2184488 * Attest: Replace example asymmetric key-pair WORKING: SHA-1: 4743e6731b0fe8a00ceebfd74da098c7676ac6e0 * Crypto: Add IPC compatibility Thanks, Andrej From: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Sent: Friday, June 14, 2019 4:00 PM To: Andrej Butok <mailto:andrey.butok@nxp.com> Cc: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: Re: Is TFM_PSA_API broken? Hi Andrej, As I said, that workaround only works for specified case. Debugging these failed cases with this patch applied will lead you into heavy core debugging. We need to find out the root cause, why the assert is triggered? There is no reason that all partitions go into block state, unless there are some improper modification in core or secure partitions. Please check your modification in SST partition, try to print something in your SST thread, to see why the thread keeps in block state. If a client calls psa_connect/psa_all, SPM would activate the partition into running state with function tfm_spm_send_event(). The correct call routine should be (psa_call has the similar routine): tfm_sst_test_2001->psa_connect->...->SVC_Handler->tfm_svcall_psa_connect->tfm_spm_send_event->....-> (your partition thread). Please remove the workaround patch, and try to debug to see if the call routine is correct. Thanks. -Ken ________________________________________ From: Andrej Butok <mailto:andrey.butok@nxp.com> Sent: Friday, June 14, 2019 8:13 PM To: Ken Liu (Arm Technology China) Cc: mailto:tf-m@lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: mailto:TF-M@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <mailto:Antonio.DeAngelis@arm.com> > Cc: mailto:tf-m@lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: mailto:tf-m@lists.trustedfirmware.org > Cc: nd <mailto:nd@arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M > <mailto:tf-m-bounces@lists.trustedfirmware.org%3cmailto:tf-m-%0b> > mailto:bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok > via TF-M > > Sent: 13 June 2019 15:46 > > To: > mailto:tf-m@lists.trustedfirmware.org%3cmailto:tf-m@lists.trustedfirmw > are.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > mailto:TF-M@lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%3D&reserved=0 -- TF-M mailing list mailto:TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M > > Sent: 13 June 2019 15:46 > > To: > tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

2
3
0 0

T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Thomas Törnblom

I have just created T398 for integrating source cleanup to improve portability. I have just pushed a patch for review. /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 4 months

1
0
0 0

Re: [TF-M] Contribution guide, where?

by Kevin Townsend

Hi Thomas, It's a bit slim, but I assume you noticed this but are looking for further details? https://git.trustedfirmware.org/trusted-firmware-m.git/tree/contributing.rst Best regards, Kevin On Fri, 14 Jun 2019 at 13:10, Thomas Törnblom via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > I'm about to submit a set of cleanup patches but have not been able to > find the contribution guide. > > Most of the useful documentation I've found seems to be related to TF-A. > > So where is it? > > /Thomas > > -- > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> > Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 4 months

1
0
0 0

Contribution guide, where?

by Thomas Törnblom

I'm about to submit a set of cleanup patches but have not been able to find the contribution guide. Most of the useful documentation I've found seems to be related to TF-A. So where is it? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Ken Liu (Arm Technology China)

Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://review.trustedfirmware.org/c/trusted-firmware-m/+/959 I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is this > correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function API > approach. > > Probably, something serious happened during last two weeks (before it worked), > may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You can see from > existing IPC - specific build configurations which flags need to be set to make > sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M > > Sent: 13 June 2019 15:46 > > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from > platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from > audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are using the > functions (printed in the log) which are not available/disabled when > TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Hi Antonio, So, I have disabled Platform and Log services. Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is this correct? After that it becomes compliable. But when starting the regression tests, I am getting assert in tfm_thrd_conext_switch(). Terminal log: [Sec Thread] Secure image initializing! NS code is running... #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Assert:tfm_thrd_context_switch:170 So I am stuck now, and no matter what to use the IPC or the Function API approach. Probably, something serious happened during last two weeks (before it worked), may be in platform dependent code. NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). Any tips? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, June 13, 2019 5:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, "Should the Log and Platform services be disabled for IPC?" Yes, platform service and Audit Log service do not support IPC. You can see from existing IPC - specific build configurations which flags need to be set to make sure these two services are not built when IPC builds are selected. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 13 June 2019 15:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is TFM_PSA_API broken? Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Antonio De Angelis

Hi Andrej, "Should the Log and Platform services be disabled for IPC?" Yes, platform service and Audit Log service do not support IPC. You can see from existing IPC - specific build configurations which flags need to be set to make sure these two services are not built when IPC builds are selected. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 13 June 2019 15:46 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Is TFM_PSA_API broken? Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Is TFM_PSA_API broken?

by Andrej Butok

Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej

6 years, 4 months

1
0
0 0

Feature request

by Thomas Törnblom

While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 4 months

1
0
0 0

[RFC] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, Since the number of configuration files is increasing, let’s move the configuration files (ConfigXXXX.cmake) into specified directory. This would reduces the files under root directory and makes the structure more clearer. I have created the issue and patch for it: https://developer.trustedfirmware.org/T394 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 IMPORTANT NOTES: To be compatible with the existing building configurations, the existing configuration files have been forwarded into the corresponded configuration file under ./configs. Which means there are two set of configuration files under sources tree at current – but this will change soon. There is a warning while you are building with root configurations files: “Please use the configs available in the ./config sub-directory.” So please: - If you are planning to create new configuration, create it under ./configs instead of root directory - The reference of configuration files under root directory will be removed soon, please change your build system setting to reference the configuration files put under ./configs Any feedbacks please reply this mail or put comments under the issue, thanks 😉 -Ken

6 years, 4 months

1
0
0 0

PSA Developer API compliance tests

by Antonio De Angelis

Dear all, The new tag which has just been made available from the psa-arch-tests, available here: https://github.com/ARM-software/psa-arch-tests/releases/tag/v19.06_API0.9 is the one that has to be used to be able to verify PSA Developer API compliance with the latest TF-M. The procedure to follow to build and run the tests remains the same. Thanks, Antonio

6 years, 4 months

1
0
0 0

Supported versions of the Armclang compiler in the TF-M build

by Antonio De Angelis

Dear all, We are considering to drop support for older versions of the Armclang compiler (i.e. 6.7 and 6.9) to focus support on newer releases (thus increasing the requirement on Armclang version to 6.10 or higher). https://developer.trustedfirmware.org/T392 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223 If you have any specific requirement to use Armclang 6.7 or 6.9, please get in touch here or on the review. Thanks, Antonio

6 years, 4 months

1
0
0 0

Two changes merged by mistake

by Miklos Balint

Hi all, Two changes that have underwent multiple rounds of review and test were accidentally merged instead of being pushed for review and final approval. I was at fault, apologies for that. Additional tests of the changes flagged up no regression. Let me know if you have any concerns or questions, Thanks and regards Miklos

6 years, 5 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Please ping me when this tag will appear. Thank you, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, May 28, 2019 2:19 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, please find my replies inline in red. ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 May 2019 07:38 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. [Antonio] Not sure exactly what you mean here. This is the latest Crypto API header used in the development branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… And it uses handles instead of slots as I have explained earlier, handles being a newer concept. Also, please bear in mind that the PSA Crypto API development happens on this branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… , Mbed Crypto being a reference implementation of the API, which means that the API itself can have new concepts which are not part of the reference implementation yet. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. [Antonio] TF-M Crypto service is indeed aligned to latest available release of Mbed Crypto, which is Mbed Crypto 1.0.0 (dated 1st April 2019): https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… As soon as there will be new releases, TF-M Crypto will align to those. The TF-M Crypto service is not aligned to the development branch because, as mentioned, that branch undergoes active daily development and would be too difficult to track. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? [Antonio] The ew_beta0 branch was used as a temporary milestone which was using the old 0.1.0beta API. For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Best regards, Antonio Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Antonio De Angelis

Hi Andrej, please find my replies inline in red. ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 May 2019 07:38 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. [Antonio] Not sure exactly what you mean here. This is the latest Crypto API header used in the development branch: https://github.com/ARMmbed/mbed-crypto/blob/development/include/psa/crypto.h And it uses handles instead of slots as I have explained earlier, handles being a newer concept. Also, please bear in mind that the PSA Crypto API development happens on this branch: https://github.com/ARMmbed/mbed-crypto/tree/psa-api-1.0-beta , Mbed Crypto being a reference implementation of the API, which means that the API itself can have new concepts which are not part of the reference implementation yet. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. [Antonio] TF-M Crypto service is indeed aligned to latest available release of Mbed Crypto, which is Mbed Crypto 1.0.0 (dated 1st April 2019): https://github.com/ARMmbed/mbed-crypto/releases As soon as there will be new releases, TF-M Crypto will align to those. The TF-M Crypto service is not aligned to the development branch because, as mentioned, that branch undergoes active daily development and would be too difficult to track. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? [Antonio] The ew_beta0 branch was used as a temporary milestone which was using the old 0.1.0beta API. For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Best regards, Antonio Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M