Hi David,
>> There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is
used. But this limitation is excessive.
>This limitation assumes that bare metal environment usually runs in sequence.
Since PSA APIs are blocking, it would be waste memory if mailbox slots are more than 1.
But it makes sense to me to support integrating a TF-M binary with various
NS use cases, which is also the one of enhancement goals of build split.
I’m glad to convert this blocking limitation into a non-blocking information
message, and let users decide.
Good to hear it.
>> More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization,
it’s just important to validate that number of slots doesn’t not exceed maximum supported by design.
>It is straightforward to add a step for NS and S to negotiate the mailbox slot number in runtime. TF-M
can add a field to set NS mailbox slot number in runtime. It is initialized to S number until NS mailbox requests to update it.
>Mailbox initialization is platform specific implementation right now, while
an additional initialization step might not be backward compatible.
It could break existing NS integration projects on dual-core platforms, which
starts submitting mailbox messages after TF-M secure receives NS mailbox addresses.
I’d suggest using the LSB bit in the NS in the mailbox queue address value,
which is passed from NS to S during mailbox initialization, to notify TF-M S side if NS is going to negotiate the mailbox slot number.
I think we can solve this problem by refactoring
ns_mailbox_queue_t. We can add a number of slots allocated by NS to this structure as a first member. Than it will be good to cache this number in mailbox partition to avoid changing this number on the fly and creating an unwanted backdoor.
>> TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that
are not shared but used by non-secure side only. Which means that it’s important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem:
>I personally prefer to the 2nd option to restructure the NS mailbox
structures a bit, since it is more extensible.
Of course, 2nd option is more complex. We can take a try at first.
If 2nd option is too complicated, we can take 1st option.
>> It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t)
defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only,
>It makes sense to me to move them to tf-m-tests.
Some fields, such as nr_used_slots, can only be updated inside NS mailbox operation. Otherwise, it requires complex synchronization between test threads and weaken the multi-core stress tests.
Those fields can be moved to a test specific structure from NS mailbox queue. But NS mailbox implementation
has to be updated to access this test specific structure.
Good point. I think this problem will be solved if the previous one will be solved by splitting shared and non-secure data. I mean that this data will not affect secure side.
Regards,
Roman.
From: David Hu <David.Hu@arm.com>
Sent: Thursday, November 16, 2023 09:52
To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.org
Subject: Re: Reduce dependency of NS Mailbox structure on non-secure configurations
|
Caution: This e-mail originated outside Infineon Technologies. Do not
click on links or open attachments unless you
validate it is safe. |
Hi Roman,
Much appreciated. Your suggestions make lots of sense to me.
Can I suggest continuing to discuss the improvements in detail in the mailing list?
> There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive.
This limitation assumes that bare metal environment usually runs in sequence. Since PSA APIs are blocking, it would be waste memory if mailbox slots are more than 1.
But it makes sense to me to support integrating a TF-M binary with various NS use cases, which is also the one of enhancement goals of build split.
I’m glad to convert this blocking limitation into a non-blocking information message, and let users decide.
> More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it’s just important to validate that number of slots doesn’t not exceed maximum supported
by design.
It is straightforward to add a step for NS and S to negotiate the mailbox slot number in runtime. TF-M can add a field to set NS mailbox slot number in runtime. It is initialized to S number until
NS mailbox requests to update it.
Mailbox initialization is platform specific implementation right now, while an additional initialization step might
not be backward compatible.
It could break existing NS integration projects on dual-core platforms, which starts submitting mailbox messages after TF-M secure receives NS mailbox addresses.
I’d suggest using the LSB bit in the NS in the mailbox queue address value, which is passed from NS to S during mailbox initialization, to notify TF-M S side if NS is
going to negotiate the mailbox slot number.
> TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it’s important to decide
which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem:
I personally prefer to the 2nd option to restructure the NS mailbox structures a bit, since it is more extensible.
Of course, 2nd option is more complex. We can take a try at first. If 2nd option is too complicated, we can take 1st option.
> It looks like there is data needed for test suite only (nr_tx and
nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only,
It makes sense to me to move them to tf-m-tests.
Some fields, such as nr_used_slots, can only be updated inside NS mailbox operation. Otherwise, it requires complex synchronization between test threads and weaken the multi-core stress tests.
Those fields can be moved to a test specific structure from NS mailbox queue. But NS mailbox implementation has to be updated to access this test specific structure.
Best regards,
Hu Ziji