Task protection using ARM9

[Joel Sherrill]

Craig S. Steele wrote:
> At 12:11 PM -0500 6/29/07, Charles Steaderman wrote:
>   
>> We have employed just this method (two distinct "applications" 
>> chosen at boot time) on previous projects. Unfortunately, this 
>> project does not have quite so clear a modal distinction between the 
>> two application feature sets. And there is a case where both need to 
>> execute at the same time. While I agree that the additional overhead 
>> for the inclusion of "thread protection data" in the context switch 
>> would add some time, I believe that the processor that we have 
>> chosen would have no trouble keeping up. I am more interested in 
>> everyone's feeling about scope of work, how much of the RTEMS kernel 
>> would be affected, etc. The other piece that would need to be 
>> handled would be access exception handlers, although this would be 
>> application specific.
>>     
>
> If you've got the CPU performance to tolerate a fixed-ratio 
> round-robin scheduling and a heavyweight context switch, you could 
> implement a very-low-level virtual machine abstraction layer 
> underneath RTEMS and periodically switch between the two virtual 
> machines, with a full (possibly lazy) register and ATU context 
> switch.  If you've got a reasonable ATU and adequate data memory, you 
> could run two text-segment-shared copies of RTEMS as a 
> time-multiplexed dual processor with shared-memory communications. 
> If you wanted to be serious about the protection, you'd have to run 
> RTEMS and the application code in user mode, which would (a) require 
> ferreting out all RTEMS privileged-mode instructions and register 
> access and putting that code in supervisor-mode SYScalled routines in 
> the VMAL, (b) figuring out appropriate device mappings in the (two) 
> address maps if you want direct user-mode device access, and (c) 
> working out an exception handling registration system in the 
> supervisor-mode VMAL for user-mode exception-event upcall handlers. 
> This sounds like a lot, but I think a clean partition is possible, 
> and the idea of mapping multiple virtual machines onto a set of 
> physical machines is probably one of the easier migrations paths to a 
> multi-core future :-)
>   

I think this is likely the easiest approach.  This would give
you execution and memory separation.  I think if you proposed
a simple "hypervisor" interface, we could use it as the basis
for similar work on other CPUs.

It has the advantage of the you aren't changing RTEMS as
much as changing the ARM port to be to an ARM virtual
machine container.

Ideally it could meet the general ARINC requirements of
time and space separation and be structured in a way that
it could be ported to other CPUs.

One of the issues I worry about when people mention this
type of work with RTEMS is that the execution environment is
really equivalent to a single process.  That means that all
stack memory, data, etc is physically accessible by all threads,
RTEMS services, TCP/IP stack, drivers, etc.  If you start to
impose a barrier between application and RTEMS, then you
will have to be careful when crossing that barrier since it
could come into play in many ways.

There was some discussion of memory protection from
the European space community.  I don't know what the status
of that is or what design ideas they had.

Sounds like a lot of fun to work on. :-D  Winter time is coming
up and I can't play outside much more so if you want help,
I would be happy to work on this.

--joel
> Craig
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>