[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