Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.lang.c
Subject: Re: Insecure hardware (was Re: gets(3) nonsense)
Message-ID: <33420@oliveb.olivetti.com>
Date: 28 Nov 88 18:54:46 GMT
References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <4869@bsu-cs.UUCP> <14733@mimsy.UUCP> <1189@cps3xx.UUCP>
Sender: news@oliveb.olivetti.com
Reply-To: chase@Ozona.UUCP (David Chase)
Organization: Olivetti Research Center, Menlo Park, CA
Lines: 25

In article <1189@cps3xx.UUCP> rang@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