🚀 go-pugleaf

The whole area of virtual memory and MMU's with respect to AmigaDOS and Exec,
etc. has been hashed over quite a bit, but Rob Peck's recent posting on it
got me thinking again. Here's another two bits worth:

Have a task for the kernel. It maps all of real memory linearly.
For a user task, map memory linearly, but only those parts that belong to
that task. Have a large part of the system available as execute only. Try to
execute as much of the system calls (library calls, device calls, etc.) as
possible under the map of the user task.

This scheme provides protection, but no true virtual memory. For many
purposes (not UNIX, unfortunately) that would be fine.

If a system is to be secure, it has to check system call parameters before it
blindly goes using them, or it must use them only under the memory map of
the owning task. The former (checking) can be quite expensive for some of
the Amiga's library calls, so we want as much as possible to be done using
the latter. To do this, we want the bulk of the library and system code
available in the user task address space, so that calls can be direct (i.e.
we don't "go through the gate" until as late as possible, and until as much
as possible has been checked by just using it within the user task's map).

There are a lot of problems here (such as where to draw all the lines), but
if we have to programmatically check all parameters to all library calls,
etc., then the poor Amiga isn't going to run very fast. Those checks would
also add a lot to the bulk of AmigaDOS, and would need a lot of work to
implement correctly.

Any structure allocated by a system call should, if possible, be in system
space and only readable to the user task. For example, when opening a window,
the returned window structure should only be readable by the caller, but
read-writeable by the system. The same goes for everything that the
window structure points at (this requires system library routines to create
all of the structures, like gadgets, menus, etc. that are now owned by the
user task, so that they can be owned by the system). This puts some crimps
into the styles of those who like to roll their own (like me, when I move
a narrow screen into the middle by pokeing the dyOffset in the ViewPort!),
but some provisions could be made by adding more library calls, which could
check things once, on setup, rather than on each using call.

So, how far off the wall am I this time?

-- 
Chris Gray		Myrias Research, Edmonton	+1 403 428 1616
	{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg