TF-M July 2019

tf-m@lists.trustedfirmware.org

19 participants
56 discussions

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…

7 years

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

7 years

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

7 years

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

7 years

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

7 years

[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

7 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M July 2019