uITRON4.0 Specification Memory Protection Extension (Page9)

1.2.Specification Policy Development and Target

 

For adding access protection functionality to memory and kernel objects of uITRON4.0 Specification, following policies and targets are setup.

(1)    All the 3 purposes described in the previous sections will be covered by one specification.

More specifically, complete protection will be provided so that even malicious programs cannot breach the protection, and it will be used as base for other purposes by allowing to abbreviating one part. For that, the specification should be easy to remove the protection functionalities which cause large overhead.

 

At one side, it is important to correct the existing application architecture model to use the protection functionality, at another side, it is also strongly considered to introduce the protection without correcting the application as can as possible. The specification will target to make both cases possible.
 

(2)    The Specification will aim towards implementation with less overhead

 

For this, as said above, in addition to making possible to remove the functionality with large overhead, the following 2 policies are set.

 

(A)  There is no need for address conversion

 

(B)   By using Static settings, lot of space will be provided for optimization

 

However, the extent to which the overhead can be reduced using these policies will depend on the Hardware (MMU etc.) used for memory protection. Moreover, to provide the full fledged protection, some level of overhead is unavoidable.

 

(3)    Make the specification as simple as can

 

It is important to make the specification simple for the user to easily understand the behavior of the system. Understanding the behavior of the system is important not to implement security hole by mistake.

 

Though the simple specification will contribute to minimize the overhead, since it is allowed to omit a part of protection functionality in implementation, even if the specification is complex, it would not be a big problem from the view point of overhead.

 

(4)    Multiple Address space and multiple ID spaces are not supported

 

To reduce the overhead, the multiple address space which requires address translation will not be supported. Though it is basic to have same physical address and logical address, it is fine to have some kind of address translation between logical address and physical address using implementation definition. Moreover, multiple ID space also is not supported. However, in future versions, the extension for multiple address space and multiple ID space may be investigated.