Argument validity checking (addresses)

[Gregory G. Woodbury]

In article <10542 at june.cs.washington.edu>
machaffi at fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie) writes:
>
>ggw at wolves.uucp (Gregory G. Woodbury) writes:
>>When a subroutine depends on the user to pass addresses (strings, structures,
>>or functions) that the subroutine is going to use, and the subroutine wants
>>to be robust about not killing the process if the user makes a mistake,
>>validity checking the aruments passed is one of the front line defenses.
>
>I must be missing something here, but what can a function do when
>it finds an invalid address besides printing an error message and
>exiting?  If the function can't do anything, then you might as well
>let the operating system catch it with an illegal memory access.

	True, the function can only complain to the calling program
that the service request is invalid.  If the calling program wishes to
perform a fix-up and/or display an error message, that is up to the
programmer using the function.  After all, the operating system tells the
program why a system call failed (usually - thats why there's the extern
int errno ;-).
	What I don't want to happen is for the program to come to a screeching
crash and dump core (or whatever) all over the machine's disks.  The original
complaint arises from the fact that there is no *portable* method to catch
invalid addresses so that the function can report to the caller that the
service request is incorrect.

>
>Even if the various checks could determine that the address is within
>the process' address space, there is no way to determine if it contains
>legal data without accessing it.  Thus, there is no way to tell
>beforehand if the address is valid.

	There are two kinds of validity confused here.  One does have to
depend on the caller to provide some things,  on the other hand, the
function should try to be robust in preventing the caller from shooting
itself in the foot.  The validity I was trying to insure was that the
subroutine can pull bytes (or whatever) from the given address, or that
the given address can be called as a function without *immediately* killing
the process.

	This kind of robustness is important in (mainly) two kinds of
systems - fault tolerant systems and in secure systems.  In a fault tolerant
system, the function should report that a fault has occurred and let the
operating system retry however it chooses.  In a security conscious system,
the *probe* should determine if the caller has sufficient privledge to
access the data.

	As I commented to someone somewhere. The complaint perhaps should
be directed to the POSIX standards people to see if there might be some
way to have to OS provide the service in some standard way.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw at cds.duke.edu  ggw at ac.duke.edu  ggw%wolves at ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>