- TF-M - lists.trustedfirmware.org

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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M