[ECOS] announcing: memory protection for eCos / PowerPC ...
Wed May 28 11:42:00 GMT 2003
I am anxious to hear this feature's release!
I meet fllow problems:
In my projects, there are many peripheral chips:
Two Flash memory (1 for boot, 1 for file system)
One Dram bank
Two~four FPGA chips
One CPLD memory space.
So four couples of Data-BAT is not enough.
memory protection is need in some cases.
I want to prevent text segment from being written. I think is a more security.
And in our program, I want to change some page's attribute like cacheable, writable staticly or dynamically
BTW during our debug, some FPGA's registers changed, I didn't know if some application wrote it or Who did it. If we have memory protection, we can find it out very easily.
----- Original Message -----
From: Thomas BINDER
Sent: Wednesday, April 16, 2003 10:44 PM
Subject: [ECOS] announcing: memory protection for eCos / PowerPC ...
I would like to announce an eCos extension that provides memory protection for the MPC8265A (603e) architecture.
The memory protection is realized in two stages. Stage-I implements the paging mode of the 603e. It allows to (statically) define an arbitrary number of pages that can be accessed at runtime. Exception vectors are set up to print a stack trace in case of a memory fault.
Stage-II implements a full process environment that allows to define several processes each with a private address space. The design more or less follows a proposal by Frank W. Miller ("Simple Memory Protection for Embedded Operating System Kernels"). By accessing all kernel primitives via a process api the kernel is fully protected from the application (i.e., the processes).
Care was taken to minimize necessary changes to the existing eCos version. Some parts, however, needed to be adapted. This includes the (PowerPC) HAL, the GDB stub, and parts of the kernel. New cdl options were introduced to enable / disable the paging mode, and to configure MMU related things (e.g. page table size and location, ...), respectively. Stage-II was implemented as a separate package which heavily relies on stage-I but should otherwise be architecture independent.
The GDB stub was extended to allow debugging of a protected application. In case the stub is enabled a SIGSEGV is reported to the debugger (instead of printing a stack trace).
Stage-I has been thoroughly tested for the last 3-4 months. Our application extensively uses eCos device drivers (serial, ethernet, PCI, flash, ...), the IP-stack, libc (sprintf), and the GDB stub.
Stage-II is relatively new and was finished a month ago.
I'm soon going to prepare a patch to the eCos main branch. Any advice on what additional information needs to be prepared would be very welcome. Probably I need to start writing ChangeLog entries ...
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss