- TF-M - lists.trustedfirmware.org

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

6 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

6 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

6 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

6 years

1
0
0 0

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

by DeMars, Alan

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

6 years

2
1
0 0

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

by DeMars, Alan

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

6 years

2
1
0 0

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

by Ken Liu (Arm Technology China)

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

6 years

1
0
0 0

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

by Ken Liu (Arm Technology China)

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

6 years

1
0
0 0

augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

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

6 years

1
0
0 0

Design proposal: Changing secure service call in library model

by Mate Toth-Pal

Hi All, I'm planning to change the way secure services are called in Library model. The design proposal can be found here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2201/ Please note that the changes proposed by this document does not affect the PSA dev API, and does not affect IPC model. Please share your opinion in gerrit comments Thanks, Mate

6 years

1
0
0 0

TF-M Presentations at SanDiego Linaro Connect

by Shebu Varghese Kuriakose

Hi, Here is a link to TF-M presentations from Linaro Connect held in San Diego last month https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_connect_san… Archive of all TF-M presentations can be found in https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/ Regards, Shebu

6 years, 1 month

1
0
0 0

Regression test - SST - MAX_ASSET_SIZE

by Vikas Katariya

Hi, This would test the interface for NS and S with the set, get and remove with maximum `SST_MAX_ASSET_SIZE` and different sizes for all platforms (including feature-twincpu targets in the near future). It uses a common 4K buffer in total to assist with read and write of asset data. We need to make sure we are able to perform this operation flawlessly on all the targets. Patch Review Request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2167 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2168 Thanks & Best Regards, Vikas Katariya 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, 1 month

1
0
0 0

Re: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR

by Jamie Fox

Hi Thomas, One way this can happen is if the QSPI driver is being executed in place from QSPI, so the device is never idle because instructions are being fetched from it. On Musca-A, MCUboot is copied to Code SRAM before being executed to avoid this issue. There is some code in the Armclang/GCC scatter/startup files to support this. Is there something similar implemented for the IAR port? 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: 27 September 2019 15:40 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /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, 1 month

2
1
0 0

Issues with qspi_ip6514e_set_spi_mode with IAR

by Thomas Törnblom

I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /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, 1 month

1
0
0 0

Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot

by Tamas Ban

Hi, In case of no further comment on the proposal I'm planning to merge it by Monday. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 24 September 2019 10:22 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot Hi, The design proposal about the integration of TF-M secure bootloader (MCUBoot) with HW key(s) are close to finalize: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ If you are interested in the topic and have a comment / suggestion then please share it. Tamas From: Tamas Ban Sent: 03 July 2019 17:50 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Design proposal for HW crypto key integration in TF-M secure boot Hi all, PSA Trusted Boot and Firmware Update specification requires the support of at least one immutable root of trust public key (ROTPK) for firmware verification. It is beneficial to be able to provision these keys during the factory life-cycle of the device independently from any software components. The current key handling solution in TF-M secure boot does not supports this key provisioning process. MCUBoot requires compile time built-in public key(s) for image verification. The following design proposal addressing this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Feel free to add any comments you want on the review! BR, Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] Please enable -pedantic-errors for gcc builds

by Ken Liu (Arm Technology China)

Hi Thomas, We tried to enable the "-pedantic-errors" flags and finished some fix. Some of them mentioned in your last mail has been pushed, and updated at: https://developer.trustedfirmware.org/T475 The reason we do not enable it as default is that there some sources files from the external project, which causes inconvenience to enable this. Please help to review these patch to see if it is acceptable for the issue for now, after that we could find a chance to merge it. And we can enable this flag internally and create more patches to fix the tf-m native source in future. 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: Saturday, August 17, 2019 5:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Please enable -pedantic-errors for gcc builds Hi Thomas, This is a very helpful suggestion. Since I am doing some cleanup these days, let me try this option and see how much we need to improve. I have created an task for tracking this: https://developer.trustedfirmware.org/T475 And, do you have an error report could be share? You can attch the log in the task if you do have some. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, August 16, 2019 4:24 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Please enable -pedantic-errors for gcc builds I'm now looking at compilation issues with our standards compliant compiler, and I run into one issue after another that are due to the use of non-standard C allowed by gcc and armclang. Things like zero sized arrays, which are fairly easy to fix by making sure that they have at least one element, but there are other issues that may not be as easy to solve. The latest issue is illegal pointer arithmetic on void * in the IPC code. --- ... [ 20%] Building C object app/secure_fw/CMakeFiles/tfm_s_obj_lib.dir/core/ipc/tfm_svcalls.o msg->invec[invec_idx].base += bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",595 Error[Pe852]: expression must be a pointer to a complete object type msg->invec[invec_idx].base += num_bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",666 Error[Pe852]: expression must be a pointer to a complete object type tfm_memcpy(msg->outvec[outvec_idx].base + msg->outvec[outvec_idx].len, ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",750 Error[Pe852]: expression must be a pointer to a complete object type ... --- I suggest enabling "-pedantic-errors" for gcc, and also for clang, if it has a similar setting, to avoid having illegal C code creeping into tf-m. 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

6 years, 1 month

1
0
0 0

T398/T413

by Thomas Törnblom

This is a notification of a patch I pushed yesterday. It consists of standard C source cleanup and initial toolchain support for IAR Embedded Workbench. The target is Musca A and I will provide further support for the psoc6 once the twincpu branch has been merged to master. The Musca A port is not yet fully functional but debugging is in progress. Thanks, /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, 1 month

1
0
0 0

Re: [TF-M] platform-specific hw initialization

by Ken Liu (Arm Technology China)

Hi Andrei, I have taken a look at give some tiny comment -- the idea is good for now since some extra platform initialization is needed. Thanks /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Friday, September 27, 2019 1:00 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] platform-specific hw initialization Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] platform-specific hw initialization

by Kevin Townsend

Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > 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

6 years, 1 month

1
0
0 0

platform-specific hw initialization

by Andrei Narkevitch

Hi All, We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? Thanks, Andrey Narkevitch Cypress Semiconductor 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, 1 month

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Robert Rostohar

Hi Mate, Thanks for the detailed explanation and confirmation that the SAU region number reference can be removed. This will enable using CMSIS-Zone to configure also TF-M in an easy way. I would appreciate if some can create a ticket to track progress. Thanks, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday 26 September 2019 09:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone 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 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 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, 1 month

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Mate Toth-Pal

Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone 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 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, 1 month

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Summer Qin (Arm Technology China)

Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone 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 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, 1 month

2
1
0 0

Please continue reviewing the merging patches from feature-twincpu branch

by David Hu (Arm Technology China)

Hi all, Sorry for frequent review requests of merging feature-twincpu back. To avoid making it more annoying, I combine three topics here. Please check the details below. 1. NS part changes NSPE mailbox, NS PSA client call interface in multi-core topology, mailbox initialization in NS App main(). https://review.trustedfirmware.org/q/topic:%22twincpu-merge-ns%22+(status:o… 2. Multi-core memory access check Multi-core specific memory access check since multi-core platform cannot rely on the memory check provided by CMSE. A dedicated design document is uploaded, which has been reviewed and accepted on feature-twincpu branch https://review.trustedfirmware.org/q/topic:%22twincpu-merge-mem-check%22+(s… 3. Changes to linker script Several changes to linker script to enable multi-core build: Adjust secure data sections layout to save MPU region and memory resource on Armv6-M/Armv7-M Add a RAM code section to support running code from RAM. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-link-script%22+… This should be the last review request/last merge step before pushing specific multi-core platform support, I promise, at least in Sept. 😊 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: Tuesday, September 24, 2019 2:07 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the changes to TF-M core/SPM and mailbox from feature-twincpu branch Hi all, Here is the forth step of merging feature-twincpu back to master branch. It includes the changes to TF-M core/SPM and SPE mailbox implementation. Please help review the patches via https://review.trustedfirmware.org/q/topic:%22twincpu-merge-core-mailbox%22… I planned to split those features into multiple topics but failed due to the dependencies between them. They are the key part of multi-core communication, plus the NS mailbox part. I'd like to introduce the components a little bit below. 1. Common PSA client call handlers Multi-core topology invokes PSA client call via mailbox, rather than by calling veneers. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2019/ extracts out common PSA client call handlers from existing svcalls. Single-Armv8-M and multi-core topology can implement their own PSA client call functions respectively and invoke the common PSA client call handlers. 2. Remote Procedure Call (RPC) RPC layer sits between TF-M SPM and underlying SPE mailbox implementation. It decouples the actual mailbox implementations to TF-M SPM and defines several callbacks for underlying mailbox. 3. SPE mailbox As the name implies, it implements the mailbox functionalities and RPC callbacks in SPE. It also defines mailbox HAL APIs for platforms. The NSPE part mailbox will be uploaded later. 4. Generic multi-core functionalities This part adds several TF-M core functions, with multi-core specific implementations, such as tfm_nspm_thread_entry () and tfm_psa_ipc_request_handler(). 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: Friday, September 20, 2019 5:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review topology changes for supporting diverse topology use cases Hi all, Would you please help review the following patches to support multi-core topology in TF-M? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-topology%22+(st… Those patches prepare for multi-core support being merged from feature-twincpu branch to master branch. It is the third step of the merging back progress. The previous steps are multi-core build enhancement and Armv6-M/Armv7-M arch support below. If it sounds interesting to you, I'm glad to share more details about multi-core development and plan of merging it back to master. 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: Thursday, September 19, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review Armv6-M/Armv7-M support patches Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji -- 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, 1 month

1
0
0 0

Re: [TF-M] TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, The ITS design document has been on review for quite a while now, so I plan to merge it this week. If anyone still wants to make any comments, please do so soon here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 The ITS implementation is also open for review in this series of patches: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1730 Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: 22 July 2019 12:00 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Internal Trusted Storage service design proposal 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M