[ECOS] Re: Memory protection

[Bart Veer <bartv@cygnus.co.uk>]

>>>>> "Chris" == Chris Waters <c.waters@celsius.co.nz> writes:

    Chris> From what I can see at the moment ecos provides no support
    Chris> for memory protection. Does anyone have any feel for how
    Chris> easy/hard it would be to add memory protection to the
    Chris> kernal for processors that provide it?

The question here is exactly what you want memory protection for?
The current eCos system is oriented towards multi-threaded
applications rather than multitasking. It is assumed that the
application consists of multiple threads which interact through a
single shared address space, using appropriate synchronisation
primitives such as mutexes and condition variables to control access
to this shared data. In this model memory protection makes little
sense (although some useful debugging tricks become possible).

Memory protection is appropriate for a different type of system where
there are multiple tasks or processes in separate address spaces, and
interaction between the processes happens via e.g. pipes and mmap()'d
regions. There are some very significant overheads associated with
this model. Enabling the MMU properly requires significant code
overheads becausing initializing and managing an MMU is non-trivial.
There are data overheads because you need page tables etc. There are
some run-time performance penalties associated with memory accesses.
Typically interactions between separate processes require one or more
system calls and hence crossing protection boundaries, which is
expensive. Finally kernel calls usually have to involve a system trap
which adds more overhead and which makes it much more difficult to
eliminate functionality that is not actually needed by the
application. 

The current version of eCos is intended to support the deeply embedded
part of the market, without precluding more advanced applications. The
assumption has to be that cpu cycles and all types of memory will be
in short supply, and many applications would not want to enable the
MMU even if support was available. Therefore we have not yet
implemented any form of memory protection in eCos, we have
concentrated our efforts on other parts of the system. On some
architectures it is necessary to a do a certain amount of MMU
manipulation to get e.g. the cache working, see the PowerPC MPC860 HAL
package for an example. It should be possible to hook into that and
set up a particular address map that meets the application's
requirements - the current release would need a little bit of tweaking
for this.

In the medium to long term we are likely to add some support for MMUs.
This will be configurable so that application developers can examine
the costs and the benefits involved, and decide for themselves whether
or not it is worthwhile. There are actually a number of possible uses
for MMUs:

1) it provides a way of doing automatic stack extension with
   relatively low overheads. This is useful for more complicated
   applications where it may be too difficult to determine stack
   requirements by static analysis. It does restrict stack sizes to
   multiples of the hardware page size.

2) if there is some sort of access to the outside world, e.g. via an
   internet connection, it is possible to download system patches and
   set up the MMU so that some bits of the system get executed from
   RAM rather than from ROM. For some applications this can provide a
   cost-effective alternative to flash memory.

3) if the ROM is a scarce resource then it is possible to store some
   of the code in a compressed form, decompressing it into RAM as and
   when required. The MMU provides a way of detecting accesses to code
   that is not currently available in RAM.

4) limited protection support, primarily for debugging purposes, for
   example the ability to invalidate certain parts of the address
   space like location 0.


Bart Veer // eCos net maintainer