- TF-M - lists.trustedfirmware.org

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Minos Galanakis

Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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, 12 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Kumar Gala

This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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, 12 months

1
0
0 0

Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following * Use a reStructuredText grid table to define dependencies * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. Thanks, Dev 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, 12 months

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Gyorgy Szing

Hi Kumar, there are some internal discussions on how "build system provisioning" and dependency handling can be enhanced. For now the most convenient might be to use the CI configuration files available here: https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 18 October 2019 15:53 To: David Vincze <David.Vincze(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New tool requirement in TF-M My point was that having them in a file that you an pass to pip install -r would be a useful thing and make setup easier for the user. - k > On Oct 18, 2019, at 2:59 AM, David Vincze <David.Vincze(a)arm.com> wrote: > > Hi Kumar, > > We also have one in TF-M: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/4/doc > s/user_guides/tfm_sw_requirement.rst > > David > > -----Original Message----- > From: Kumar Gala <kumar.gala(a)linaro.org> > Sent: 17 October 2019 15:52 > To: David Vincze <David.Vincze(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] New tool requirement in TF-M > > Might be good to have some kinda of requirements.txt that lists out all python modules needed. > > In zephyr there is: > > https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requi > rements.txt > > You can see the install/setup guide details here: > > https://docs.zephyrproject.org/latest/getting_started/index.html#insta > ll-python-dependencies > > - k > >> On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi All, >> >> We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. >> It adds the cbor 1.0.0 Python package to the list of tools that are >> required to build TF-M. Once it is merged, this package has to be >> installed in the build environment, otherwise the builds will fail. >> The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). >> >> Regards, >> David Vincze >> -- >> 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

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Kumar Gala

Might be good to have some kinda of requirements.txt that lists out all python modules needed. In zephyr there is: https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requiremen… You can see the install/setup guide details here: https://docs.zephyrproject.org/latest/getting_started/index.html#install-py… - k > On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. > It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package > has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the > following command: pip3 install --user cbor > (or manually after downloading the package from here: https://pypi.org/project/cbor/). > > Regards, > David Vincze > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

2
2
0 0

New tool requirement in TF-M

by David Vincze

Hi All, We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). Regards, David Vincze

7 years

1
0
0 0

Modifying the bootloader - runtime sw interface

by David Vincze

Hi all, I have 3 patches on review (/2149<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2149/>, /2148<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2148/>, /2147<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/>) that will change the interface between MCUBoot and the runtime SW. Currently the bootloader passes the measured boot status data to the attestation service through a shared memory area as individual claims (in TLV format). With these changes the boot status data will be encoded to CBOR format at build time and will be added to the image manifest during the image signing process. The bootloader will share this data the same way as before (as a new type of TLV), however the attestation service will have to handle this data differently as it's already CBOR encoded. This can cause the attestation tests to fail if an older MCUBoot image has been used with a newer build of the secure image or vice versa. To address this issuse / provide backward compatibility the new 'ATTEST_BOOT_INTERFACE' variable will be introduced in the build system (in one of the above patches) to be able to get back the old behavior. For this the 'ATTEST_BOOT_INTERFACE' variable has to be set to "INDIVIDUAL_CLAIMS" in the CMake configuration step: "cmake -G"Unix Makefiles" -DPROJ_CONFIG=../configs/ConfigRegression.cmake -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS ../" The old behavior will be retained for a while, however we have an intention to remove it entirely from the code in the future. Please let me know if you have any questions or concerns. I'd also welcome any feedback on the reviews. Best regards, David Vincze

7 years

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by Miklos Balint

Hi Alan, Thanks for the suggestion and the clarifications provided to Ken. During the course of the mail thread, you raised a design principle issue as well as implementation details, and I'll try to address the design principle question later as that is an important topic, but first allow me to touch on one implementation detail for this specific feature: While convenient in GCC, weak symbols are not defined by the C99 standard and their use and syntax is therefore compiler-specific, which is not good from a portability point of view and may cause difficulties with different toolchains. In my opinion a preprocessor-based solution e.g. in the switch-case of the generic SVC handler would be more portable. Could you check the feasibility of that approach? The default expansion could be empty for platforms that do not implement platform-specific SVC handlers, and an arbitrary list of additional case statements for SVC numbers implemented by the platform code for your platform. Please let us know your thoughts, Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 10 October 2019 15:45 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > 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: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to > support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> 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: [TF-M] augmenting the SVC_Handler_IPC() >> to support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, >>> flag), SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of >>> user buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' >>> <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> 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 > -- > 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

2
1
0 0

TF-M's Documentation website is live

by Minos Galanakis

Hi all, TF-M's documentation has now launched. The project is using Sphinx to render the documents into HTML which can be accessed via the link bellow: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… The main website has been updated with shortcuts to the new location which can be accessed by navigating at https://www.trustedfirmware.org/ -> Documentation -> Docs > TF-M Thanks, Minos

7 years

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > 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: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> 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: [TF-M] augmenting the SVC_Handler_IPC() to >> support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), >>> SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of user >>> buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M