[gclist] memory protections and system calls

[Fergus Henderson]

Paul R. Wilson, you wrote:
> 
> The problem is this: when you access-protect memory and pass a pointer
> to something in that protected memory to a system call, most OS's will
> choke---they'll signal an unrecoverable error, or silently corrupt
> data, or simply die.  (We've brought SunOS down several times this way.)
[...]
> We view this as a bug in the OS,

Yes, if the OS crashes, that *is* definitely a bug.

> but we still have to deal with it.

Unfortunate but true.  You have my sympathy ;-)

> 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.)

I believe the traditional Unix approach has been for the OS call to
return an error status and set errno to EFAULT ("Bad address").  What
you suggest would clearly be nicer from a user's perspective, but from
an OS implementor's perspective I believe it is a lot harder to
implement.

The program can handle things by checking for EFAULT, figuring out
which address is causing the problem, invoking the appropriate handler
function to unprotect the memory, and then reinvoking the system call.
It could perhaps be done transparently by the library function which
invokes the system call.  (The whole thing is similar in some ways to
the handling of EINTR.)  Of course I don't imagine that your average
standard C library does this...

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.