I have read that certain Lisp interpreters require executable stack for
code generation and a non-executable stack will break these. Can some
one provide me more information on why and when the stack is used for
run-time code generation and Is there any way to avoid that?
Also provide me any pointers available which discusses these?
Thanks
Reji
From: John Thingstad
Subject: Re: Requirement for an executable stack-Lisp interpreters
Date:
Message-ID: <op.tfoau7khpqzri1@pandora.upc.no>
On Sun, 10 Sep 2006 18:53:45 +0200, <············@gmail.com> wrote:
> I have read that certain Lisp interpreters require executable stack for
> code generation and a non-executable stack will break these. Can some
> one provide me more information on why and when the stack is used for
> run-time code generation and Is there any way to avoid that?
> Also provide me any pointers available which discusses these?
>
>
> Thanks
> Reji
>
Not generally true.
In ACL there was a bug that made it require this, but that has now been
fixed.
I use both LispWorks and ACL under windows and they both work with DEP on
all programs.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Duane Rettig
Subject: Re: Requirement for an executable stack-Lisp interpreters
Date:
Message-ID: <o0ac57uedm.fsf@franz.com>
"John Thingstad" <··············@chello.no> writes:
> On Sun, 10 Sep 2006 18:53:45 +0200, <············@gmail.com> wrote:
>
>> I have read that certain Lisp interpreters require executable stack for
>> code generation and a non-executable stack will break these. Can some
>> one provide me more information on why and when the stack is used for
>> run-time code generation and Is there any way to avoid that?
>> Also provide me any pointers available which discusses these?
>>
>>
>> Thanks
>> Reji
>>
>
> Not generally true.
> In ACL there was a bug that made it require this, but that has now
> been fixed.
Allegro CL has never executed code on the stack. Code vectors are
managed in the heap, not on the stack.
Microsoft tends to highlight stack-data execution as the source of
many viruses; it is very easy in C to create and jump to executable
code on the stack, but the real issue with DEP is that it disallows
by default execution of _any_ writable data, whether in the stack or
on the heap. Special coding is required to work around this, and the
"bugs" you saw were really enhancements to the data model in order to
match the new DEP restrictions. We didn't get it right the first
time, and a few bugs have been fixed after the initial release of a
new shared-library for the DEP patch. But none of these involved any
data being executed on the stack.
We regard MS's zealous restriction on execution to be unfortunate,
though we certainly wouldn't fauilt them for trying to make their
product more secure - it's just that prior to this other operating
systems (notably, Unix-like systems) which tend to be regarded as
relatively secure, have not made that kind of restriction for any
extended length of time (whenever some idealistic
code-should-never-be-self-modifiable developer places such
restrictions in their systems, they quickly discovered that it was a
mistake - more programs than they might have imagined write data
intended for later code execution). At least MS provided tools and
techniques to mitigate the restrictions, and though not ideal, they
allowed us to work around the DEP issues.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: John Thingstad
Subject: Re: Requirement for an executable stack-Lisp interpreters
Date:
Message-ID: <op.tfpobvsapqzri1@pandora.upc.no>
On Mon, 11 Sep 2006 08:05:41 +0200, Duane Rettig <·····@franz.com> wrote:
>
> Allegro CL has never executed code on the stack. Code vectors are
> managed in the heap, not on the stack.
>
My bad. What I meant was it required DEP to be turned off when run
or the program would abort. Wheteher code was run on the stack or not
didn't concern me. A quick email to Franz and running update patches
fixed that in 15-20 minutes. (Should not be necessary anymore.)
Thanks for the explanation of DEP in ACL.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
············@gmail.com wrote:
> I have read that certain Lisp interpreters require executable stack for
> code generation and a non-executable stack will break these. Can some
> one provide me more information on why and when the stack is used for
> run-time code generation and Is there any way to avoid that?
> Also provide me any pointers available which discusses these?
Other have answered for Lispworks & ACL.
I've never had a problem with this. AFAIK Lisps don't generally
assemble code on the stack. They build some assembly language, maybe
with a C compiler, get an assembler to make it into machine code, then
use an OS call to append this to the running executable. Some may make
machine code directly, I don't know.
Rob Thorpe <·············@antenova.com> wrote:
+---------------
| I've never had a problem with this. AFAIK Lisps don't generally
| assemble code on the stack. They build some assembly language, maybe
| with a C compiler, get an assembler to make it into machine code, then
| use an OS call to append this to the running executable.
+---------------
GCL & ECL do this, I think.
+---------------
| Some may make machine code directly, I don't know.
+---------------
CMUCL, SBCL, and I'm pretty sure ACL, Lispworks, & Scieneer as well,
generate compiled code directly into memory. [Dunno 'bout Corman Lisp...]
Classically, most Lisps with compilers did generate compiled code
directly into memory.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ari Johnson
Subject: Re: Requirement for an executable stack-Lisp interpreters
Date:
Message-ID: <m2irjtzm7y.fsf@hermes.theari.com>
····@rpw3.org (Rob Warnock) writes:
> Classically, most Lisps with compilers did generate compiled code
> directly into memory.
Does anyone here remember enough history to know which came first
between Lisp and macro assemblers? I don't know if it was always done
this way, but I know that in modern Lisps it is much easier to write
the whole system in Lisp than to invoke an external assembler and load
the assembled code into memory.
Ari Johnson wrote, On 9/12/06 5:29 PM:
> Does anyone here remember enough history to know which came first
> between Lisp and macro assemblers?
I don't remember enough history, but Google does.
http://www.thocp.net/timeline/1955.htm
In 1956: "APT (automatic Programmed Tool) is developed by D.T. Ross.
With this piece of software one can create shortcuts in software
development. The tool writes the programmers text or "macro's" out in
assembly."
Some history of the first Lisp implementations, in the form of email
dialog, so you have to do some reading to get to conclusive information:
http://www.iwriteiam.nl/HaCAR_CDR.html
"Email from Steve Russell
I wrote the first implimenation of a LISP interpreter on the IBM 704 at
MIT in early in 1959. I hand-compiled John McCarthy's 'Universal LISP
Function'."
The IBM 704 assembler did have a macro facility:
http://www.frobenius.com/fap.htm (search for the word 'macro' on the page)
--
Sidney Markowitz
http://www.sidney.com
Sidney Markowitz wrote, On 9/12/06 7:16 PM:
> Ari Johnson wrote, On 9/12/06 5:29 PM:
>> Does anyone here remember enough history to know which came first
>> between Lisp and macro assemblers?
>
> I don't remember enough history, but Google does.
And apparently I don't have enough memory to remember to type everything
I intend to before I hit Send.
The other relevant reference is the origin of macros in Lisp, which in
http://www.cs.umbc.edu/331/resources/papers/Evolution-of-Lisp.pdf
on page 41 is described as occurring in 1963. The paper contains the
full text of the MIT AI Lab memo that described it.
--
Sidney Markowitz
http://www.sidney.com
Greetings!
····@rpw3.org (Rob Warnock) writes:
> Rob Thorpe <·············@antenova.com> wrote:
> +---------------
> | I've never had a problem with this. AFAIK Lisps don't generally
> | assemble code on the stack. They build some assembly language, maybe
> | with a C compiler, get an assembler to make it into machine code, then
> | use an OS call to append this to the running executable.
> +---------------
>
> GCL & ECL do this, I think.
>
GCL does not require executable stack, but does require non-randomized
sbrk. GCL autodetects when the OS is trying to do this and resets its
'personality'. All GCL apps work is such a mode on the latest
security setups.
The reason is simple -- having a contiguous heap, which can grow up to
the limits supported by the OS, gives the user more power, and is
easier to handle internally.
Take care,
> +---------------
> | Some may make machine code directly, I don't know.
> +---------------
>
> CMUCL, SBCL, and I'm pretty sure ACL, Lispworks, & Scieneer as well,
> generate compiled code directly into memory. [Dunno 'bout Corman Lisp...]
>
> Classically, most Lisps with compilers did generate compiled code
> directly into memory.
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah