Hi Jamie,
>As I understand it, one of the uses of the secure flash is to store
crypto keys, so the dependency from Crypto to the secure flash needs to be
kept.
The crypto keys you mentioned in your previous reply are the crypto keys
used to encrypt the communication channel between host MCU with the secure
Flash? Or the secrets such as (public/private)key pairs used in TLS
protocol?
If the former,I think these keys may be stored in NVM memories such as OTP
or internal flash of MCU,and these keys can be loaded and imported as
transient keys in RAM with a key handle during such as secure boot, then
we can call PSA Crypto service with these key handles, in this case, the
dependency from Crypto to secure flash doesn't exist.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021
苏州工业园区苏虹西路55号
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
Poppy Wu/CHINA/MXIC
2020/12/16 14:20
To
Edward Yang <EdwardYang(a)mxic.com.cn>
cc
Subject
Re: [TF-M] Discuss how to support secure Flash in TF-MLink
Hi Jamie,
Thank you for your reply.
You are right,the secure Flash can be used to store sensitive information
like TLS private keys,in this application, during TLS handshake,Crypto
service depends on secure Flash driver to get these private keys,so the
dependency from Crypto to the secure flash needs to be kept.
And you mentioned implementation of crypto functions varies depending on
the platform(some platforms have hardware crypto module while the others
have to depend on software crypto library), platfrom without HW crypto
module could use AES encrypt/decrypt functions from a software crypto
library (e.g. Mbed TLS). As I understand, currently tfm Crypto service
also uses Mbed TLS as the backend software crypto library by default. I am
wondering if secure Flash driver could call this Mbed TLS library APIs
(such as mbedtls_aes_encrypt（）) directly?
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021
苏州工业园区苏虹西路55号
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org>
2020/12/16 03:02
Please respond to
Jamie Fox <Jamie.Fox(a)arm.com>
To
Edward Yang <EdwardYang(a)mxic.com.cn>
cc
nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org"
<tf-m(a)lists.trustedfirmware.org>
Subject
Re: [TF-M] Discuss how to support secure Flash in TF-M
Hi,
The trouble with calling the PSA Crypto functions from your secure flash
driver is that it will create a circular dependency between the ITS
service and the Crypto service. Crypto uses ITS to store its keys, but
then the secure flash driver calls the Crypto service again to encrypt the
data. These circular dependencies between partitions are forbidden in
TF-M.
As I understand it, one of the uses of the secure flash is to store crypto
keys, so the dependency from Crypto to the secure flash needs to be kept.
That means the dependency on the Crypto service in the secure flash driver
needs to be avoided. I think ideally the best way to do this would be to
use hardware crypto functions available in the platform instead of PSA
Crypto APIs inside the flash driver, but if no crypto hardware is
available then you could use AES encrypt/decrypt functions from a software
crypto library (e.g. Mbed TLS).
Hope that helps.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward
Yang via TF-M
Sent: 15 December 2020 10:08
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Discuss how to support secure Flash in TF-M
Dear all,
I would like to discuss how to add secure Flash support in TF-M.
Firstly, I want to describe the motivation of adding secure Flash support
in TF-M.
Currently ARM TF-M provides protected storage service(PS service for
short) to implement security protection on external normal storage,
however this type external normal storage is still vulnerable to
unauthorized physical modifications/erasing and cloning.Macronix and other
Flash memory suppliers have developed secure Flash products to enhance the
security in external flash devices. Secure Flash enables mutual
authentication between itself and host MCU/SoC and only permits the
authorised host to perform access, besides, the communication channel
between host MCU/SoC and secure Flash is protected by encryption,
authentication, data scrambling, and frame sequencing with monotonic
counters as shown below, so the secure Flash provides dependable defense
against unauthorised access, man-in-the-middle, replay, sniffing and other
security threats.
If we port TF-M to a platform which uses secure Flash as external
flash,then secure Flash driver should be added to TF-M.However,compared
with nomal external flash driver,secure Flash driver needs extra crypto
functions(such as calling AES crypto functions to encrypt/decrypt data),
if the secure Flash driver is placed in platform folder in TF-M code
structure as a backend of ITS service, I don't know whether secure Flash
driver is allowed to call Crypto service(such as psa_aead_encrypt(),
psa_aead_decrypt() )directly.If not, are there any other solutions to
perform crypto operations in secure Flash driver?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi Jamie,
Thank you for your reply.
You are right,the secure Flash can be used to store sensitive information
like TLS private keys,in this application, during TLS handshake,Crypto
service depends on secure Flash driver to get these private keys,so the
dependency from Crypto to the secure flash needs to be kept.
And you mentioned implementation of crypto functions varies depending on
the platform(some platforms have hardware crypto module while the others
have to depend on software crypto library), platfrom without HW crypto
module could use AES encrypt/decrypt functions from a software crypto
library (e.g. Mbed TLS). As I understand, currently tfm Crypto service
also uses Mbed TLS as the backend software crypto library by default. I am
wondering if secure Flash driver could call this Mbed TLS library APIs
(such as mbedtls_aes_encrypt（）) directly?
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021
苏州工业园区苏虹西路55号
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org>
2020/12/16 03:02
Please respond to
Jamie Fox <Jamie.Fox(a)arm.com>
To
Edward Yang <EdwardYang(a)mxic.com.cn>
cc
nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org"
<tf-m(a)lists.trustedfirmware.org>
Subject
Re: [TF-M] Discuss how to support secure Flash in TF-M
Hi,
The trouble with calling the PSA Crypto functions from your secure flash
driver is that it will create a circular dependency between the ITS
service and the Crypto service. Crypto uses ITS to store its keys, but
then the secure flash driver calls the Crypto service again to encrypt the
data. These circular dependencies between partitions are forbidden in
TF-M.
As I understand it, one of the uses of the secure flash is to store crypto
keys, so the dependency from Crypto to the secure flash needs to be kept.
That means the dependency on the Crypto service in the secure flash driver
needs to be avoided. I think ideally the best way to do this would be to
use hardware crypto functions available in the platform instead of PSA
Crypto APIs inside the flash driver, but if no crypto hardware is
available then you could use AES encrypt/decrypt functions from a software
crypto library (e.g. Mbed TLS).
Hope that helps.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward
Yang via TF-M
Sent: 15 December 2020 10:08
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Discuss how to support secure Flash in TF-M
Dear all,
I would like to discuss how to add secure Flash support in TF-M.
Firstly, I want to describe the motivation of adding secure Flash support
in TF-M.
Currently ARM TF-M provides protected storage service(PS service for
short) to implement security protection on external normal storage,
however this type external normal storage is still vulnerable to
unauthorized physical modifications/erasing and cloning.Macronix and other
Flash memory suppliers have developed secure Flash products to enhance the
security in external flash devices. Secure Flash enables mutual
authentication between itself and host MCU/SoC and only permits the
authorised host to perform access, besides, the communication channel
between host MCU/SoC and secure Flash is protected by encryption,
authentication, data scrambling, and frame sequencing with monotonic
counters as shown below, so the secure Flash provides dependable defense
against unauthorised access, man-in-the-middle, replay, sniffing and other
security threats.
If we port TF-M to a platform which uses secure Flash as external
flash,then secure Flash driver should be added to TF-M.However,compared
with nomal external flash driver,secure Flash driver needs extra crypto
functions(such as calling AES crypto functions to encrypt/decrypt data),
if the secure Flash driver is placed in platform folder in TF-M code
structure as a backend of ITS service, I don't know whether secure Flash
driver is allowed to call Crypto service(such as psa_aead_encrypt(),
psa_aead_decrypt() )directly.If not, are there any other solutions to
perform crypto operations in secure Flash driver?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hello,
Probably the next Technical Forum will not be very popular, planned on Thursday, Dec 24 (US friendly time zone).
Let's cancel this slot to meet again in January 7.
Wish you pleasant holidays and Happy New Year.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
The purpose of code review guidelines is trying to provide some reference for reviewers. It is still in the evaluation stage. After it gets matured then we can pointer to this document as a required reference.
I updated some part of it, the main changes:
- The private symbol (static inside a source file) can have a prefix for easier source viewing, a reader would know it is a symbol in the file he/she is viewing which can avoid cross-files 'find reference' operation in the editor.
- Clarifies the header file types and the usage: A 'interface' header file is for abstraction, and a typical 'include' header contains exported functionalities for external module usage.
Please help to take a look if you have time - as this is one of the upcoming updates, I will treat the review contents out of the changed lines into a new patch if it is possible.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7577
Thanks.
/Ken
Hi,
The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M.
As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS).
Hope that helps.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: 15 December 2020 10:08
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Discuss how to support secure Flash in TF-M
Dear all,
I would like to discuss how to add secure Flash support in TF-M.
Firstly, I want to describe the motivation of adding secure Flash support in TF-M.
Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats.
[cid:image001.gif@01D6D313.1B0E4E10]
If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn<http://www.mxic.com.cn/>
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Dear all,
I would like to discuss how to add secure Flash support in TF-M.
Firstly, I want to describe the motivation of adding secure Flash support
in TF-M.
Currently ARM TF-M provides protected storage service(PS service for
short) to implement security protection on external normal storage,
however this type external normal storage is still vulnerable to
unauthorized physical modifications/erasing and cloning.Macronix and other
Flash memory suppliers have developed secure Flash products to enhance the
security in external flash devices. Secure Flash enables mutual
authentication between itself and host MCU/SoC and only permits the
authorised host to perform access, besides, the communication channel
between host MCU/SoC and secure Flash is protected by encryption,
authentication, data scrambling, and frame sequencing with monotonic
counters as shown below, so the secure Flash provides dependable defense
against unauthorised access, man-in-the-middle, replay, sniffing and other
security threats.
If we port TF-M to a platform which uses secure Flash as external
flash,then secure Flash driver should be added to TF-M.However,compared
with nomal external flash driver,secure Flash driver needs extra crypto
functions(such as calling AES crypto functions to encrypt/decrypt data),
if the secure Flash driver is placed in platform folder in TF-M code
structure as a backend of ITS service, I don't know whether secure Flash
driver is allowed to call Crypto service(such as psa_aead_encrypt(),
psa_aead_decrypt() )directly.If not, are there any other solutions to
perform crypto operations in secure Flash driver?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
Tel: 86-512-62580888 EXT: 3147
Fax: 86-512-62585399 ZIP: 215021
http://www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi all,
I have pushed for review the new Internal Trusted Storage and Protected Storage HAL designs, as well as an initial implementation for AN521. I will update the change for all other platforms once the design has settled down.
It expands the ITS and PS HALs to cover all flash and filesystem configuration parameters required from the platform. The CMSIS Flash Driver is exposed to abstract the flash device itself.
ITS is updated to use the new HALs, with its_flash_info_external.c, its_flash_info_internal.c and its_flash.c removed. The ITS filesystem is updated to take a configuration struct as an initialisation parameter, which is filled using values from the HAL.
The gerrit reviews are:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4781https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7598
Kind regards,
Jamie
😉
No response got yet, as it is closing to Xmas, plan to merge them before end of this week (18th Dec) if there is no more voice.
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, December 7, 2020 3:22 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Moving partition stack into partition BSS/ZI.
Hi,
We are now allocating partition’s stack inside linker script file, and there are two external patches trying to move these stack definitions into partition’s BSS/ZI:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1
The advantages:
- Simplify the linker script/sct templating, stack items can be saved.
- Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases).
- Stack is private data, putting private data together is a direct way.
And the disadvantages:
- Stack memory and global memory may affect each other – actually we don’t apply such protecting mechanism now?
Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too.
Thanks.
/Ken
Hi all,
The build system currently fetches the latest "master" of tf-m-tests repo for building, if auto-download dependencies mode is used (which is the default).
This would break the building when:
* TF-M and tf-m-tests have dependency changes got merged
* A developer is working with a local copy of TF-M that has not been updated to the latest.
* The developer does a clean build with auto-downloading
* The build system fetch the latest tf-m-tests repo which is not compatible with the local copy of TF-M
We've seen this kind of issue reported in mailing list.
To solve this problem, the proposal<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7550> of fixing the "TFM_TEST_REPO_VERSION" to a hash or tag is raised.
With this change, the build system would download a compatible version always.
The version of the test repo is not required to be updated for every commit in the test repo.
(Guide line on when to update the version is required and it's still under discussion - welcome for ideas.)
Developers want a different version can always override "TFM_TEST_REPO_PATH" to a local copy to build.
Best Regards,
Kevin
Dear All,
The Secure Enclave patches have been merged and caused a minor source structure change.
The platform so far named musca_b1 became musca_b1/sse_200, because we added support to the other subsystem on the Musca-B1 board, musca_b1/secure_enclave.
So to build onto the old Musca-B1 platform the -DTFM_PLATFORM=musca_b1/sse_200 flag will be needed.
All information about the Secure Enclave topic can be found in these rsts:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/desig…https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer…https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
Best regards,
Mark
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M
Sent: 09 December 2020 10:11
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Secure Enclave solution in TF-M
Dear All,
The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised.
https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope…
Best regards,
Mark
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M
Sent: 03 December 2020 16:38
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] Secure Enclave solution in TF-M
Dear All,
I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback.
https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope…
Best regards,
Mark
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M
Sent: 14 September 2020 21:00
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Secure Enclave solution in TF-M
Dear All,
Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653
I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP:
https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope…
Limitations, missing features, notes:
* No support for isolation level2 on SSE-200
* Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave
* Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave
* All IPC message forwarding is a blocking call
* Only one message is put into the mailbox at a time
* Musca-B1 related documentation is not complete yet
* Generated files are not committed, manifest parser should be run before build.
* The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now
* Cmake changes are rudimentary, will be rebased to new cmake system.
Any feedback very welcomed!
Best regards,
Márk Horváth
Senior Software Engineer
Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>
Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary
www.arm.com<http://www.arm.com/>
