[ECOS] Re: Memory protection
Bart Veer
bartv@cygnus.co.uk
Sat Dec 5 10:56:00 GMT 1998
>>>>> "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
More information about the Ecos-discuss
mailing list