Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→TrustZone-based approach
==TrustZone-based approach==
This section describes in detail the solution that implemented by DAVE Embedded Systems to overcome the limitations of basic AMP configuration a to satisfy all the requirements listed in section [[#Limitations of traditional configurations|''Limitations of traditional configurations'']].
===Overview===
The major difference with respect to the traditional AMP configuration is the use of a software monitor, specifically a customized version of TOPPERS SafeG
[[File:Safeg-arch-english.png|thumb|center|400px|Nagoya University TOPPERS SafeG architecture]]
As shown in the picture, the monitor can be viewed as a software layer that lies between Trust/Non-trust worlds and underlying hardware. The monitor is responsible for:
* enabling and initializing TrustZone in order to protect memory regions that must not be accessible by Non-secure world* TBDASTBD AS
About operating systems, Linux has been chosen for Non-trust world, while [http://www.freertos.org FreeRTOS ] has been selected for the Trust world. At the time of this design, the Linux/FreeRTOS combination has proven to be the most appealing for the majority of applications that this solution addresses. Nevertheless different combinations are possible{{efn|For example TOPPERS project makes use of [http://www.toppers.jp/en/index.html different RTOSes].}}.
About the multi-processing scheme, AMP has been used{{efn|The monitor can support either AMP or SMP configurations.}}.
These choices lead to the configuration depicted in the following picturefigure.
[[File:Bora-wp001 01.png|thumb|center|400px|DAVE Embedded Systems' TrustZone-enabled AMP solution]]
# acceptance into the mainline linux kernel
# possibility to customize the implementation in order to control the degree of isolation between the two worlds.
The first criteria guarantees future maintainability on linux Linux side. Generally speaking, it is expected that the GPOS needs relatively frequent maintenance activities in order to add new functionalities or fix vulnerabilities and bugs. In contrast, RTOS side is typically more stable and easier to maintain. Therefore, selecting a communication mechanism that is included in mainline linux Linux kernel is preferable from the point of view of overall system maintainability.
The second criteria is very important because, as discussed in following sections, it is absolutely crucial that the communication channel - <u>that affects directly the degree of isolation between W1 and W2</u> - is very flexible in order to adjust it to application-specific requirements as needed.
Different solutions have been evaluated - , including but not limited to
''OP-TEE''<ref name="OP-TEE">''Open Portable Trusted Execution Environment'', https://www.linaro.org/blog/core-dump/op-tee-open-source-security-mass-market/</ref>,
''dualoscom''<ref name="Sangorrin's thesis">Daniel Sangorrin Lopez, ''Advanced integration techniques for highly reliable dual-os embedded systems'', Nagoya University (Japan), 27th July 2012, http://ir.nul.nagoya-u.ac.jp/jspui/bitstream/2237/16907/1/k9888.pdf</ref>,
''RPMsg''<ref name="RPMsg-TI">http://omappedia.org/wiki/Category:RPMsg</ref>, <ref name="RPMsg-linux">https://lwn.net/Articles/464391/</ref>
and ''OpenAMP''<ref name="OpenAMP">https://github.com/OpenAMP/open-amp</ref>- and the . The choice has fallen on ''RPMsg '' that has been considered the best compromise among the available options. It should be recalled that this choice is reversible, in the sense that if application-specific requirements can not be met by ''RPMsg', <u>it can be replaced by a different communication scheme</u>.
===L2 cache management===
