[ECOS] Re: Memory protection

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

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

    >> The question here is exactly what you want memory protection
    >> for? The current eCos system is oriented towards multi-threaded
    >> applications rather than multitasking.

    Chris> I was thinking more about protecting the OS from errant
    Chris> user code. When user code is run-time downloadable there is
    Chris> a danger that it won't be as well tested as the kernel.

    Chris> I haven't really given much thought to the practical
    Chris> difficulties of doing this. You mention the overhead when
    Chris> making system calls. Is this because the MMU mappings need
    Chris> to be replaced with the system mappings when control passes
    Chris> to the OS and back to the user mappings when it switches
    Chris> back to user code?

A reasonable question. There are a number of different approaches,
depending on the exact capabilities of the MMU and just how much
protection you want between the kernel and application code. As an
example consider a mutex lock operation. Currently the mutex data
structure lives in application space and all of its fields are
directly accessible. Suppose that you want to make the actual mutex
data structure inaccessible. The data type cyg_mutex_t now has to
change from a full data structure to a handle, and a lock operation
would involve something like the following steps:

1) a procedure call to cyg_mutex_lock() as before, possibly inlined.

2) this would perform a system trap, i.e. a software interrupt. The
   cost of such an interrupt is a lot smaller than a hardware
   interrupt because much more is known about the machine state, but
   it can be non-trivial. This is how the protection boundary between
   application and kernel code is crossed.

3) the cyg_mutex_t handle now has to be translated to a pointer to the
   actual data structure.

4) depending on the processor and the implementation, the kernel may
   already have access to the protected memory courtesy of doing the
   system trap. Otherwise it has to do some manipulation of the MMU
   tables, possibly the caches, etc.

5) do the actual lock operation.

6) undo any damage caused during step (4).

7) return from the software interrupt.

8) return back to application code.

Steps (2), (3), (4), (6) and (7) are new overhead. They involve extra
code, some extra data, and cpu cycles. Other areas of the system need
to do extra work as well, for example the way interrupt handlers/DSRs
interact with application code, but this should give you some idea of
what is involved.

Bart Veer // eCos net maintainer