Re: [SC-L] Programming languages used for security
The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer? I forget whether it's returning an error code analogous to EFAULT or raising an access violation, but I'm fairly sure it's one of them (at least under the versions I used). Either would be reasonable, the latter arguably more so (just as under Unix, it would arguably be more sensible to generate a SIGSEGV/SIGBUS rather than returning EFAULT). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: [SC-L] Programming languages used for security
ljknews wrote: At 11:38 AM -0700 7/13/04, Blue Boar wrote: ljknews wrote: The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer? Return SS$_ACCVIO. So you put in an error handler that catches access ciolation before you try to use the pointer? OK, fair enough. What if the pointer points to memory you own, but not the right kind? I have always been under the impression that raw pointers could always cause you problems. I've assumed that a secure language would have to eliminate that as a type. BB
Re: [SC-L] Programming languages used for security
At 10:39 AM -0700 7/14/04, Blue Boar wrote: ljknews wrote: At 11:38 AM -0700 7/13/04, Blue Boar wrote: ljknews wrote: The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer? Return SS$_ACCVIO. So you put in an error handler that catches access ciolation before you try to use the pointer? OK, fair enough. What if the pointer points to memory you own, but not the right kind? The inner mode code probing ensure that the calling mode has the ability to read and/or write the memory (according to the semantics of the particular interface. The inner mode code does not distinguish between stacks and various heaps, just that the memory is readable or writable by the calling process in the mode from which the call is made. I have always been under the impression that raw pointers could always cause you problems. I've assumed that a secure language would have to eliminate that as a type. As have I. -- Larry Kilgallen
