Hi,
The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too.
For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread's stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away.
So SPM must work under MSP to avoid touching his standing place - and, the used part of initial thread stack needs to be clean up, for security issues. Now we can't find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware.
The patches is on the way for this purpose - and follows the patches of jumping to ns without cmse call - cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode.
Patches would come later (I am testing if it could on different platforms).
Thanks.
/Ken
Hi All,
To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/.
The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different.
Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat….
You can send mail or add comments directly in patches if you have any questions or comments.
Thanks,
Edison
Hi,
We met some issues while implementing logging APIs like printf:
* The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers.
* If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env.
* Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?)
So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly.
Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs).
Please provide your thinking, or what kind of logging API you are using.
Thanks
/Ken
Hi,
I want to arise this topic again - some patches are blocked due to feature implementation but I think now it is a good chance since staging tag has been done.
Will notify you with the patches - don't worry, it is just about some file rename in core/spm folder so if your patch does not rely on these folders a simple rebase should work for your patch.
/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: Thursday, August 29, 2019 4:49 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [RFC] Code restructure of core/spm
Two more patches added under this topic:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1836https://review.trustedfirmware.org/c/trusted-firmware-m/+/1837
BR
/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: Thursday, August 15, 2019 3:15 PM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: Re: [TF-M] [RFC] Code restructure of core/spm
>
> Hi,
> The first patch for moving header files is ready at:
> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561
> Comments are welcome. I had thought to push patches together but looks
> like it would block other patches for a while to show a neat merged
> list, so I would push them one by one.
>
> Will keep you update when incoming patches are ready.
>
> BR
>
> /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: Thursday, August 1, 2019 11:12 AM
> > To: tf-m(a)lists.trustedfirmware.org
> > Cc: nd <nd(a)arm.com>
> > Subject: [TF-M] [RFC] Code restructure of core/spm
> >
> > Hi,
> >
> > Several patches for code restructure is coming. Before I post the
> > gerrit items, I want to collect your feedback on this. These changes contain:
> >
> > - Move header files into dedicated directory for easy include, and
> > clean the included headers in sources;
> > - Change some files' name to let them make more sense.
> > - Move SPM related files into 'spm' folder instead of putting them in 'core'.
> > - Move some interface files into 'ns_callable' since they are interfaces.
> > - Remove 'ipc' folder after all files in it are well arranged.
> >
> > I will try to do these patches together so they can be merged together.
> > But before that I want to request for comments about this, feel free
> > to reply in this thread or comment on the task (add yourself if you
> > are missing as
> > subscribers):
> > https://developer.trustedfirmware.org/T426
> >
> > BR
> >
> > /Ken
> >
> >
> > --
> > 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
Hi Reinhard & Ken,
There are definitely some challenging trade-offs, and the right approach can depend on the system and use case.
PSA Firmware Framework is a architectural interface design for deployment on different CPU/SoC designs, and defines an interrupt framework that:
1. can be implemented on these different architectures
2. is aligned with the security & isolation principles of the Framework
PSA-FF does not stop an implementation (such as TF-M) from providing additional interrupt frameworks that provide lower-latency for some components. These will obviously be non-portable (to other PSA-FF implementations) and may have security trade-offs if the ISR runs in a privileged secure state to achieve performance requirements.
As you suggest, although it is possible to discuss the options in general - it is only possible to make good design decisions with real use cases for integrating hardware devices into the secure side of the system, and the required behaviour of the interrupt handlers.
There is a substantial evidence that weakening the isolation requirements is not typically balanced by keeping the critical code simple, reviewed and secure - based on the experience of TrustZone and other TEE software implementations. I agree that such careful code development is possible, but it is not normal (at the moment).
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: 18 December 2019 13:49
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] irq handling in library mode
Ken, thanks for the reply.
My take on that is that instead of adding overhead to ISR, ISR should be executed fast.
For ISRs we should publish clear guidelines that explain potential side effects of ISR execution.
These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution.
How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available.
What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway.
Reinhard
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.
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.
Hi Matt,
Sorry not to review your patch as soon as possible because you forget adding me to the reviewer list😊
I had reviewed it now.
By the way, there is a contributing process in TF-M which require to create a related ‘task’ for task management. I had helped to create one for this issue. Please help to create it the next time. I can help you if you have any problems with it. For more detail, you can refer to this:https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/proce…,
Hi All,
Here is the patch link: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2923. Please help to review it
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M
Sent: Friday, December 20, 2019 12:49 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] irq handling in library mode
Hi Edison,
If it is a bug, I will upsteam a patch to fix it later.
Thanks,
Matt
Hi Edison,
If it is a bug, I will upsteam a patch to fix it later.
Thanks,
Matt
At 2019-12-19 16:43:18, "Edison Ai via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote:
Hi Matt,
Sorry not got your point in the first time.
Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example.
Can you upstream a patch to fix it?
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M
Sent: Wednesday, December 18, 2019 9:54 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] irq handling in library mode
Hi Edison,
Thanks for your reply.
In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows,
|
interrupted_ctx_stack_frame_t
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition.
If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack.
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
Now the stack is show as below,
|
interrupted_ctx_stack_frame_t (used)
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack.
At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in
the stack of partition A, as current code shown below,
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t.
My question is exactly about the above scenario.
If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows,
|
interrupted_ctx_stack_frame_t (used)
|
|
handler_ctx_stack_frame_t (used)
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
Please read the file tfm_secure_irq_handling.rst again , and help to check about this question.
Thanks,
Matt
At 2019-12-17 14:22:13, "Edison Ai \\(Arm Technology China\\) via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote:
Hi Matt,
Thanks for your email.
Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now.
First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.”
Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this:
SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2.
As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below:
|
SP2 stack pointer -à
|
|
|
|
Caller_partition_indx(handler)
|
|
|
Partition_sate(handler)
|
SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3.
As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer.
|
SP2 stack pointer -à
|
Partition_state(interrupted)
|
|
|
Caller_partition_indx(handler)
|
|
|
Partition_sate(handler)
|
And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore.
We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status.
So I think it should be ok in the current design for the interrupt in the library model.
I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M
Sent: Monday, December 16, 2019 1:08 PM
To:tf-m@lists.trustedfirmware.org
Subject: [TF-M] irq handling in library mode
Hi TFM experts,
I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows:
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx.
runtime_data->ctx_stack_ptr +=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.
And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx
runtime_data->ctx_stack_ptr -=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx.
runtime_data->ctx_stack_ptr -=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
Please help to check.
Thanks,
Matt
Hello,
We have a new blog post detailing TF-M in Lyon here: https://www.trustedfirmware.org/blog/trusted_firmware_at_lyon/
Thank you,
Augustina Adjei
[cid:image001.jpg@01D5B688.34C152B0]
Mawuelome - Seyram Augustina Adjei
Central Engineering - Open Source Software Group
augustina.adjei(a)arm.com
110 Fulbourn Road, Cambridge, CB1 9NJ
www.arm.com<http://www.arm.com/>
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.
Hi all,
The triggering behavior of the Trusted Firmware-M CI has been adjusted. Tests jobs will no longer trigger automatically. Instead when the patch submitter would like their code to be tested, they will need to assert the newly introduced `Allow-CI` Gerrit voting flag.
Regards
Minos
Because of New Year holidays, the next forum is planned on Jan 9, 2020.
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M
Sent: 19 December 2019 02:37
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call - 19th December
Update the Agenda: (added TF-M profile session)
- The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion?
- TF-M and Amazon FreeRTOS integration update
- [RFC] TF-M Profile
- Cryptocell integration
Regards,
David Wang
Arm Electronic Technology (Shanghai) Co., Ltd
Phone: +86-21-6154 9142 (ext. 59142)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, December 13, 2019 2:14 AM
To: TF-M(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - 19th December
Hello,
To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics.
1. The time slot.
Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary:
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=…
Please share your thoughts and alternatives. The related question: shall we fix the time or rotating?
You can play with the time slot here:
https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea…
2. Agenda as a proposal
- The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion?
- TF-M and Amazon FreeRTOS integration update
- Cryptocell integration
- ?
Best regards,
Anton Komlev
--
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
Hi Matt,
Sorry not got your point in the first time.
Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example.
Can you upstream a patch to fix it?
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M
Sent: Wednesday, December 18, 2019 9:54 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] irq handling in library mode
Hi Edison,
Thanks for your reply.
In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows,
interrupted_ctx_stack_frame_t
handler_ctx_stack_frame_t
interrupted_ctx_stack_frame_t
...
handler_ctx_stack_frame_t
interrupted_ctx_stack_frame_t
And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition.
If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack.
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
Now the stack is show as below,
interrupted_ctx_stack_frame_t (used)
handler_ctx_stack_frame_t
interrupted_ctx_stack_frame_t
...
handler_ctx_stack_frame_t
interrupted_ctx_stack_frame_t
But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack.
At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in
the stack of partition A, as current code shown below,
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t.
My question is exactly about the above scenario.
If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows,
interrupted_ctx_stack_frame_t (used)
handler_ctx_stack_frame_t (used)
interrupted_ctx_stack_frame_t
...
handler_ctx_stack_frame_t
interrupted_ctx_stack_frame_t
Please read the file tfm_secure_irq_handling.rst again , and help to check about this question.
Thanks,
Matt
At 2019-12-17 14:22:13, "Edison Ai \\(Arm<file://(Arm> Technology China\\) via TF-M" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi Matt,
Thanks for your email.
Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now.
First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location."
Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this:
* SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2.
As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below:
SP2 stack pointer --->
Caller_partition_indx(handler)
Partition_sate(handler)
*
SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3.
As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer.
SP2 stack pointer --->
Partition_state(interrupted)
Caller_partition_indx(handler)
Partition_sate(handler)
And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore.
We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status.
So I think it should be ok in the current design for the interrupt in the library model.
I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of lg via TF-M
Sent: Monday, December 16, 2019 1:08 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] irq handling in library mode
Hi TFM experts,
I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows:
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx.
runtime_data->ctx_stack_ptr +=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.
And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx
runtime_data->ctx_stack_ptr -=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx.
runtime_data->ctx_stack_ptr -=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
Please help to check.
Thanks,
Matt
Update the Agenda: (added TF-M profile session)
- The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion?
- TF-M and Amazon FreeRTOS integration update
- [RFC] TF-M Profile
- Cryptocell integration
Regards,
David Wang
Arm Electronic Technology (Shanghai) Co., Ltd
Phone: +86-21-6154 9142 (ext. 59142)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, December 13, 2019 2:14 AM
To: TF-M(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - 19th December
Hello,
To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics.
1. The time slot.
Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary:
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=…
Please share your thoughts and alternatives. The related question: shall we fix the time or rotating?
You can play with the time slot here:
https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea…
2. Agenda as a proposal
- The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion?
- TF-M and Amazon FreeRTOS integration update
- Cryptocell integration
- ?
Best regards,
Anton Komlev
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Edison,
Thanks for your reply.
In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows,
|
interrupted_ctx_stack_frame_t
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition.
If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack.
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
Now the stack is show as below,
|
interrupted_ctx_stack_frame_t (used)
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack.
At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in
the stack of partition A, as current code shown below,
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t.
My question is exactly about the above scenario.
If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows,
|
interrupted_ctx_stack_frame_t (used)
|
|
handler_ctx_stack_frame_t (used)
|
|
interrupted_ctx_stack_frame_t
|
|
...
|
|
handler_ctx_stack_frame_t
|
|
interrupted_ctx_stack_frame_t
|
Please read the file tfm_secure_irq_handling.rst again , and help to check about this question.
Thanks,
Matt
At 2019-12-17 14:22:13, "Edison Ai \\(Arm Technology China\\) via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote:
Hi Matt,
Thanks for your email.
Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now.
First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.”
Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this:
SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2.
As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below:
|
SP2 stack pointer -à
|
|
|
|
Caller_partition_indx(handler)
|
|
|
Partition_sate(handler)
|
SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3.
As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer.
|
SP2 stack pointer -à
|
Partition_state(interrupted)
|
|
|
Caller_partition_indx(handler)
|
|
|
Partition_sate(handler)
|
And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore.
We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status.
So I think it should be ok in the current design for the interrupt in the library model.
I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M
Sent: Monday, December 16, 2019 1:08 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] irq handling in library mode
Hi TFM experts,
I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows:
void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct interrupted_ctx_stack_frame_t *stack_frame =
(struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
}
void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx)
{
struct spm_partition_runtime_data_t *runtime_data =
&g_spm_partition_db.partitions[partition_idx].runtime_data;
struct handler_ctx_stack_frame_t *stack_frame =
(struct handler_ctx_stack_frame_t *)
runtime_data->ctx_stack_ptr;
stack_frame->partition_state = runtime_data->partition_state;
stack_frame->caller_partition_idx = runtime_data->caller_partition_idx;
runtime_data->ctx_stack_ptr +=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
}
My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx.
runtime_data->ctx_stack_ptr +=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.
And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx
runtime_data->ctx_stack_ptr -=
sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t);
I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx.
runtime_data->ctx_stack_ptr -=
sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t);
Please help to check.
Thanks,
Matt
Ken, thanks for the reply.
My take on that is that instead of adding overhead to ISR, ISR should be executed fast.
For ISRs we should publish clear guidelines that explain potential side effects of ISR execution.
These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution.
How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available.
What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway.
Reinhard
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.
Ken thanks for your answer.
So it is up to the PSA Framework team to define the right framework?
Reinhard
_______________________________________________________________________________
Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com>
ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362)
Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil
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.
We already have about 7 test services/partitions. It's growing.
To save resources. Is it possible to combine the test partitions to one or just few?
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M
Sent: Wednesday, December 18, 2019 12:34 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Adding a new test partition to test multi-partition scenarios
Hi all,
There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys.
Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution.
I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features.
Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
Kind regards,
Jamie
Hi all,
There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys.
Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution.
I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838 . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features.
Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790
Kind regards,
Jamie
Hi,
"... with 80 column while reviewing (not put this into document) ... "
FIY our coding standard explicitly requires 80 chars limit for C code. (See: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… )
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 18 December 2019 02:04
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Coding guideline
Hi,
For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles.
But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review.
For services, I won't propose specified limits because some of them may be external projects which is hard to be limited.
/Ken
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: Wednesday, December 18, 2019 12:40 AM
To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Coding guideline
Hi,
One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M
Sent: 17 December 2019 17:17
To: Reinhard Keil <Reinhard.Keil(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Coding guideline
On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote:
> IMHO a 80-char restriction is irrelevant with today’s screens/editors
> – it comes from the teletype time where 80 characters was the natural
> limit on CRT or punch card.
I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense.
However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one.
But, for myself, I tend to always have them at least be 100 characters.
David
--
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
Hi Reinhard,
This is correct at current and needs SFC specification to clarification in future.
The existing PSA Firmware Framework proposes a thread based Secure Partition and the IPC manner about how the information is shared between these process.
The SFC model (which is a well know model but do not have a specification yet) combines secure services as a library and makes the information-sharing mechanism complicate under isolation level 2/3, which lost the advantage of 'library' model.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: Tuesday, December 17, 2019 4:10 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Level 2/Level 3 Isolation requires IPC?
I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode.
It does not work with Secure Function Call (SFC) mode (aka Library mode).
Is it correct, and why does Level2/Level 3 isolation require IPC?
Reinhard
_______________________________________________________________________________
Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com>
ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362)
Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil
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.
Hi Reinhard,
Your approach is good for a RTOS.
For secure firmware, we need to:
* A secure partition may bind an interrupt in its manifest, which means the interrupt related logic of a secure partition should be inside secure partition's scope. (This is what the library model is doing.)
* To avoid affect non-secure RTOS execution, IRQ should be quick and heavy execution can be delay into secure partition thread. (This is what IPC model is doing).
This interrupt handling is keeping evolution, we are trying to create a proposal to provide:
* Fast ISR execution.
* Put non-urgent interrupt related logic into thread.
Now we are collecting proposals and your comment is an important input. And I think the DMA part needs to be considerate much as you have mentioned, it may bypass MPU.
If anyone is also working on this topic, please send mail in this mailing list or create an issue (developer.trustedfirmware.org).
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: Tuesday, December 17, 2019 4:04 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] irq handling in library mode
I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational:
* IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects.
* IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC.
Another reason of this relaxed approach is the usage of DMA.
* DMA is frequently controlled by IRQ
* DMA also bypasses MPU, therefore same behaviour as IRQ.
Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core.
What is wrong with that approach?
Reinhard
_______________________________________________________________________________
Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com>
ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362)
Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil
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.
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.
Hi,
For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles.
But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review.
For services, I won't propose specified limits because some of them may be external projects which is hard to be limited.
/Ken
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: Wednesday, December 18, 2019 12:40 AM
To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Coding guideline
Hi,
One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M
Sent: 17 December 2019 17:17
To: Reinhard Keil <Reinhard.Keil(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Coding guideline
On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote:
> IMHO a 80-char restriction is irrelevant with today’s screens/editors
> – it comes from the teletype time where 80 characters was the natural
> limit on CRT or punch card.
I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense.
However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one.
But, for myself, I tend to always have them at least be 100 characters.
David
--
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
Hi,
One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.)
Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M
Sent: 17 December 2019 17:17
To: Reinhard Keil <Reinhard.Keil(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Coding guideline
On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote:
> IMHO a 80-char restriction is irrelevant with today’s screens/editors
> – it comes from the teletype time where 80 characters was the natural
> limit on CRT or punch card.
I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense.
However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one.
But, for myself, I tend to always have them at least be 100 characters.
David
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
