[gclist] memory protections and system calls

[Chris Reedy]

At  3:04 PM 6/28/96 -0500, Paul R. Wilson wrote:
>We view this as a bug in the OS, but we still have to deal with it.  In
>our view, a protected page should be treated the same way by the kernel
>as by user code---the kernel should reflect the access violation back
>to the user process in the form of a user-level signal, so that the
>app can deal with it---typically by unprotecting the page and doing
>some bookkeeping before returning.  Then the kernel should resume and
>do whatever it's been asked to do.  (Like writing data from a buffer.)

Having been something of an OS hack in the past:

It is almost impossible to do this in _current_ operating systems without
making the OS dependent on user code.  This is something that no sane OS
developer will ever do.  (The problems associated with user code causing
the OS to crash and/or behave in strange and unusual ways are too much to
deal with.)  Your typical OS developer would tell you that this is not a
bug in the OS, but the OS defending itself from the user.

Some of the newer research operating systems (for example, Sun's Spring)
provide this kind of capability by restructuring the whole approach to the
interaction of user and system code.  These systems allow capabilities like
user defined virtual memory managers and file systems.  Unfortunately, I
think you're stuck until these kind of OSs become common (and my crystal
ball has no answer as to how many years that will take).

  Chris

This is an informal message and not an official Mitretek Systems position.
Dr. Christopher L. Reedy, Mail Stop Z667
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: creedy@mitretek.org  Phone: (703) 610-1615  FAX: (703) 610-1603