Insecure hardware (was Re: gets(3) nonsense)

[David Chase]

In article <1189 at cps3xx.UUCP> rang at cpswh.cps.msu.edu (Anton Rang) writes:
>  The problem lies with
>the implementation of BSD and Ultrix, which leave the stack
>executable; I can't see any reason for this offhand.

Well, I'm told that there's signal handling code that writes on the
stack and then executes it.  It's also a handy trick for implementing
partial application, which can in turn be used to implement lexical
binding of variables in nested functions for languages that aren't C
but wish to remain compatible with it.  This is VERY useful if your
intermediate/portability language IS C (no, I can't use a global
variable to simulate a lexical or display pointer, because we'll be
using threads.  Yes, I'm aware that C structure-returning conventions
are often non-reentrant, and we've dealt with that.)  Some Lisp
systems may generate code onto the stack in certain situations.

Some new machines have separate instruction and data busses and/or
caches, and this is sometimes given as a good reason for keeping
instruction and data spaces separate (protect us from undefined
results, I assume).  I'd prefer otherwise, since it isn't too hard to
write code to do the right thing (somewhat efficiently, even) if there
is a system call that allows page-by-page changing of protection or
copying of a page of data into I-space.

David