[Coco] How can you make permanent directory changes in OS-9 ml programs?

[Boisy G. Pitre]

John,

NitrOS-9 specifically doesn't offer protected memory environments on a per process basis.  A process can access any memory outside of its own process space, indeed even the MMU registers!

Security wasn't a consideration in the design of OS-9/6809, and by today's standards it is extremely susceptible to rogue programs.  The simplest way to bring down a NitrOS-9 system is to write an assembly language program that does this:

  jmp $FFFE

In fairness to Microware, OS-9 was designed to be used in closed architectured systems where all software running was known ahead of time and most likely in ROM.  Errant or rogue software wasn't a consideration for these types of systems, assuming they were built robustly enough.

That said, Microware did design the operating system with some degree of separation.  Certain system calls, as noted, can only be made from a process running in the system state.   Unlike the 68K CPU, the 6809 didn't have a separate system state mode, so the separation of user and system state is merely a distinction made by the kernel itself.  When a system call is made into the kernel, it checks to see if the caller is running in the system state or the user state, as determined by a flag in its process descriptor, I believe.  The kernel will either then allow the system call, or return an error 208 (E$UnkSvc).

Best Regards,
Boisy G. Pitre

Join our forums at http://www.tee-boy.com/forums/ to exchange ideas and join other WeatherSnoop enthusiasts.




On Sep 5, 2011, at 8:13 AM, John Kent wrote:

> OS9 does not provide a protected environment for different users does it ?
> Is it possible in any way to add DMA to the CoCo ?
> 
> It's possible on the FPGA version because you have control of the hardware. On the PC you can set a bit in the registry that clears the page RAM file on shutdown (I assume that is a process shutdown rather than a PC shutdown). This means that the content of page file RAM can't be scanned by malicious software for things like credit card numbers, passwords etc. from RAM that has been released from one process and assigned to another.
> 
> Strictly speaking a process should be run in a protected environment so that no other process has access to it's memory. OS9 should really clear RAM when a process is terminated and memory is released. The fastest way to do that is with DMA writing a constant value through RAM such as $00 or $FF or NOPs. The intel DMA controller used in the original PC performs a read into a temporary register followed by a write so it can transfer memory. You use two DMA channels and tell each channel if you want the address counter to increment or have a fixed address for a peripheral device. The 6844 on the other hand enables the I/O data bus of the peripheral and reads or writes the peripheral data directly to memory. If the peripheral is a constant value, then it can write that value through a memory block.
> 
> If you clear process memory on exit of the process, then it needs to done as quickly as possible so that the CPU isn't hung up.
> 
> The 6809 does not have a user and supervisor mode for protected instructions like the 68000. The 68000 does not support virtual memory because it can't rerun bus cycles on page faults generated by a MMU. The 68010 was designed to fix that problem. Page faults in a 6809 would have to use MRDY to stop the processor and you's need external hardware to resolve the memory management.
> 
> I presume protected OS9 system calls are some how determined by the address range they occur in.
> 
> Anyway perhaps that is all off topic.
> 
> John.
> 
> On 5/09/2011 7:37 AM, Boisy G. Pitre wrote:
>> Sorry, I was looking at the wrong system call.
>> 
>> F$GProcP is a privileged system call, so it, like F$Move, cannot be called from a user process.
>> 
>> Best Regards,
>> Boisy G. Pitre
>> 
>> Join our forums at http://www.tee-boy.com/forums/ to exchange ideas and join other WeatherSnoop enthusiasts.
>> 
>> 
> 
> -- 
> http://www.johnkent.com.au
> http://members.optusnet.com.au/jekent
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco