Friday, January 10, 2014

uITRON4.0 Specification Memory Protection Extension (Page8)

Chapter 1 Background for formation of Specification


1.1      Purpose for introducing Protection functionality

The purpose for introducing the protection functionality into the uITRON standard real time kernel can be mainly classified into the following three headings:
 
 (1) Protection functionality to ensure security

To protect the main portion of system (kernel) even in case of downloading and executing malicious programs, it is necessary the kernel should have protection functionality.

For this purpose, there should be no way to breach the security (security hole) and it is necessary to provide complete protection functionality. Moreover, it is difficult to achieve complete protection by communication between tasks through Share memory. So, there are portions in the application architecture model  that must be improved.

 (2) Protection functionality to improve the reliability
 
With the kernel having the protection functionality, even problem occurs in one part, operation of the whole system can be continued. In other words, it becomes possible to coexist the modules with different requirements of reliability.

For this purpose, it is extremely important to minimize the execution overhead. To what extent the protection has to be implemented is decided on how much the reliability requirement of each module differs and the trade-off between the overhead. Because of this, for reducing the overhead, even if there is a way to breach the protection, if the probability to occur by accident is significantly low, it can be allowed. Moreover, whether to correct the application architecture model or not, also depends on till what extent the protection is necessary.

(3) Protection functionality to support debug

With the kernel having the protection functionality, it becomes easy to isolate the problematic place when there is malfunction and it results to effective debugging. Moreover, the invisible problems can be detected at early stages.

For this purpose, there is a demand to introduce only the protection which is necessary for debug so that there won’t be any corrections in the existing applications (as can as possible).

When preparing the protection functionality for this purpose, it is better to remove protection functionality at the time of product shipment. (at many cases, it may not be removed, since it needs additional verification) On this view point, it may be desirable to implement protection functionality not in the kernel, but in the development environment (for example, ICE).
 

No comments: