Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→L2 cache management
#* gives trusted code the control of the machine.
# FreeRTOS kernel is initialized and real-time tasks are started. Under the control of the tasks running on top of the RTOS kernel, the non-trusted (NT for short) code is started{{efn|This is done via a Secure Monitor Call (referred as SMC in the rest of the document) that is handled by the monitor.}}.
===Inter-world communication===
Even if it is technically possibly to implement a system where W1 and W2 are completely isolated, the majority of real applications need a communication mechanism between the two worlds{{efn|From a different point of view, this is a sort of break in the barrier between the two worlds. As such it poses non-trivial issues in term of integrity and timeliness in the Trust world. This matter will be covered in more detail in following sections.}}.
Several options are available to implement such a mechanism, each of which having different pros and cons. Exhaustive comparison of all of them is beyond the scope of this paper. Nevertheless some aspects will be briefly discussed and some useful links will be provided to study this notable subject in more depth.
The following criteria have been taken into account to determine how to select the communication mechanism:
# acceptance into the mainline linux kernel
# possibility to customize the implementation in order to control the degree of isolation between the two worlds.
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>,
''Dual-OS communication''<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 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 application-specific requirements can not be met by RPMsg, it can be replaced by a different communication scheme.
===L2 cache management===
TBD
==Characterization and performance tests==
TBD