Re: [ECOS] Re: Memory protection

Re: [ECOS] Re: Memory protection

[Kenneth Porter]

On Fri, 27 Nov 1998 15:04:06 GMT, Bart Veer wrote:

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

I'd add the ability to write-protect code in RAM once it's read in,
both for debugging and to protect it from wild pointers in the field.
Same thing for memory-mapped non-volatile parameter memories (ie.
EEPROM).

Read-protecting code (ie. limiting it to execute-only access) would be
useful in chasing wild read pointers. (BTW, can GCC store vtables in
non-code read-only memory, so that it can have different access rights
than code or data pages? Such memory would hold read-only data objects
like strings and function pointers.)

I don't see a strong need for the MMU for multiple processes, myself.
Instead, it would serve the same purpose as a watchdog timer: to
protect a system from runtime problems.


Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com

[ECOS] Re: Memory protection

[Bart Veer]

>>>>> "Kenneth" == Kenneth Porter <kenneth_porter@kensingtonlabs.com> writes:

    Kenneth> On Fri, 27 Nov 1998 15:04:06 GMT, Bart Veer wrote:
    >> 4) limited protection support, primarily for debugging
    >> purposes, for example the ability to invalidate certain parts
    >> of the address space like location 0.

    Kenneth> I'd add the ability to write-protect code in RAM once
    Kenneth> it's read in, both for debugging and to protect it from
    Kenneth> wild pointers in the field. Same thing for memory-mapped
    Kenneth> non-volatile parameter memories (ie. EEPROM).

These would certainly be useful, although write-protecting code can
make life a bit more interesting for gdb.

    Kenneth> Read-protecting code (ie. limiting it to execute-only
    Kenneth> access) would be useful in chasing wild read pointers.
    Kenneth> (BTW, can GCC store vtables in non-code read-only memory,
    Kenneth> so that it can have different access rights than code or
    Kenneth> data pages? Such memory would hold read-only data objects
    Kenneth> like strings and function pointers.)

For ELF-based targets I believe that vtables are already put in the
.rodata section, just like strings etc. It would then be up to the
linker script to put this section at a suitable location in memory so
that it can be write-protected - including worrying about minimum page
sizes etc.

Bart Veer // eCos net maintainer

[ECOS] Re: Memory protection

[Chris Waters]

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

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

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

Chris.

[ECOS] Re: Memory protection

[Bart Veer]

>>>>> "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

[ECOS] Memory protection

[Chris Waters]

Hi,

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

I am thinking about porting ecos to the IBM PowerPC 403GC.

Chris Waters.

[ECOS] Re: Memory protection

[Bart Veer]

>>>>> "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