From: Rex Dieter
Subject: gcl-2.6.1 on Fedora Core?
Date: 
Message-ID: <c2ncjg$rlo$1@unlnews.unl.edu>
I'm unable to successfully build gcl-2.6.1 (gcl_2.6.1-30.tar.gz) on Fedora
Core.  I'm fairly certain exec-shield (and non-executable stack) is the
culprit.

I'd like to get this resolved, so we can see gcl in Fedora Extras,
submission URL:
http://bugzilla.fedora.us/show_bug.cgi?id=753

I can provide gcl developer(s) a remote shell account on a Fedora Core box
if needed.

-- Rex

From: Camm Maguire
Subject: Re: gcl-2.6.1 on Fedora Core?
Date: 
Message-ID: <544qswfrjm.fsf@intech19.enhanced.com>
Greetings!  Recently posted the following to various lists.  The
problem, BTW, is identical to GNU emacs' problem (unexec), and the
solution apparently the same, given the fedora emacs spec file.

There is a long thread about this between some Fedora people and
myself and Tim Daly on the axiom mailing list archives.

Take care,

=============================================================================
Greetings!  GCL is fully functional on FC1 without global exec-shield
shutoff provided one makes use of 'setarch'.  Built gcl and acl2
binaries are in my home directory provided by J. Shapiro.

GCL
1) setarch i386 ./configure (optional --enable-dynsysgmp, etc.)
2) setarch i386 make

ACL2
1) setarch i386 make lisp=gcl
2) setarch i386 ./saved_acl2

etc.

If there is a way in which a program can internally, i.e. from within,
do its own 'setarch' and one can explain this to me, I'd be happy to
put it in GCL, configured in when appropriate.  Or if someone can post
the sources to setarch.  At the moment, the most convenient thing
would appear to be to provide an acl2 (or maxima, gcl, axiom...)
wrapper script with the setarch i386 explicitly provided.

=============================================================================

Rex Dieter <·······@math.unl.edu> writes:

> I'm unable to successfully build gcl-2.6.1 (gcl_2.6.1-30.tar.gz) on Fedora
> Core.  I'm fairly certain exec-shield (and non-executable stack) is the
> culprit.
> 
> I'd like to get this resolved, so we can see gcl in Fedora Extras,
> submission URL:
> http://bugzilla.fedora.us/show_bug.cgi?id=753
> 
> I can provide gcl developer(s) a remote shell account on a Fedora Core box
> if needed.
> 
> -- Rex

-- 
Camm Maguire			     			····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
From: David Golden
Subject: Re: gcl-2.6.1 on Fedora Core?
Date: 
Message-ID: <e2K3c.605$qP2.2237@news.indigo.ie>
Camm Maguire wrote:


> 
> If there is a way in which a program can internally, i.e. from within,
> do its own 'setarch' and one can explain this to me, I'd be happy to
> put it in GCL, configured in when appropriate. 

I think you need to make sure the ELF binary object that is loaded
has an annotation section telling the kernel and ld.so that it needs
executable stack - google for PT_GNU_STACK.

According to the link below (near the end of the linked document), the
linker (GNU ld) included with Fedora accepts "-z execstack" to signal that
this section should be included and indicate executable stack.

http://fedora.redhat.com/docs/release-notes/
From: Camm Maguire
Subject: Re: gcl-2.6.1 on Fedora Core?
Date: 
Message-ID: <547jxsumr4.fsf@intech19.enhanced.com>
Greetings, and thanks!  We already add -Wa,--execstack to the cflags,
but this is not enough.  (I'm assuming that is equivalent to the ld
flag -- could be wrong here.)  With gcl and emacs, the problem is not
with an executable stack -- gcl never executes code off its stack.
Its just that principally speaking, unexec assumes that sbrk expanded
.data sections are contiguous -- it can't unexec an image with a hole
between where the ld-produced .data section ended and where the first
sbrk() started.  It does not appear that --execstack turns off brk
randomization.  But setarch does.  Would greatly appreciate
clarification/enlightenment/some internal marking to achieve this goal
as apart from an executable stack.

Take care,

David Golden <············@oceanfree.net> writes:

> Camm Maguire wrote:
> 
> 
> > 
> > If there is a way in which a program can internally, i.e. from within,
> > do its own 'setarch' and one can explain this to me, I'd be happy to
> > put it in GCL, configured in when appropriate. 
> 
> I think you need to make sure the ELF binary object that is loaded
> has an annotation section telling the kernel and ld.so that it needs
> executable stack - google for PT_GNU_STACK.
> 
> According to the link below (near the end of the linked document), the
> linker (GNU ld) included with Fedora accepts "-z execstack" to signal that
> this section should be included and indicate executable stack.
> 
> http://fedora.redhat.com/docs/release-notes/
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Camm Maguire			     			····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
From: David Golden
Subject: Re: gcl-2.6.1 on Fedora Core? - non-exec stack on Linux (and Windows?)
Date: 
Message-ID: <WSJ3c.602$qP2.2215@news.indigo.ie>
Rex Dieter wrote:

> 
> I'm unable to successfully build gcl-2.6.1 (gcl_2.6.1-30.tar.gz) on Fedora
> Core.  I'm fairly certain exec-shield (and non-executable stack) is the
> culprit.
> 

This probably bites several other Lisps too, not to mention loads of other
non-lisp non-C stuff.  There are fairly good reasons for the change, all
the same, though they mostly stem from C sucking, I guess.

See the end of the page at
http://fedora.redhat.com/docs/release-notes/ 
for details on exec-shield in Fedora, and instructions on how to turn the
damn thing off. Several other distros are talking about using exec-shield
at the moment.

AFAIK MS is turning on similar functionality in the next WinXP service pack,
though I don't know the details (tinfoil hat: and in MS's case, no doubt
it's an evil plot to introduce some part of their "treacherous computing"
framework quietly.)
From: Thomas F. Burdick
Subject: Re: gcl-2.6.1 on Fedora Core? - non-exec stack on Linux (and Windows?)
Date: 
Message-ID: <xcvllm85v0y.fsf@famine.OCF.Berkeley.EDU>
David Golden <············@oceanfree.net> writes:

> Rex Dieter wrote:
> 
> > 
> > I'm unable to successfully build gcl-2.6.1 (gcl_2.6.1-30.tar.gz) on Fedora
> > Core.  I'm fairly certain exec-shield (and non-executable stack) is the
> > culprit.
> > 
> 
> This probably bites several other Lisps too, not to mention loads of other
> non-lisp non-C stuff.  There are fairly good reasons for the change, all
> the same, though they mostly stem from C sucking, I guess.
> 
> See the end of the page at
> http://fedora.redhat.com/docs/release-notes/ 
> for details on exec-shield in Fedora, and instructions on how to turn the
> damn thing off. Several other distros are talking about using exec-shield
> at the moment.
> 
> AFAIK MS is turning on similar functionality in the next WinXP service pack,
> though I don't know the details (tinfoil hat: and in MS's case, no doubt
> it's an evil plot to introduce some part of their "treacherous computing"
> framework quietly.)

Turns out it is evil -- it doesn't apply to the .NET runtime.  Which
might be okay, if .NET didn't have a history of security holes.  So,
Java, Smalltalk, and Lisp, apps will suddenly stop working.  Yuck.
You can't uninstall those things, can you?

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: David Steuber
Subject: Re: gcl-2.6.1 on Fedora Core? - non-exec stack on Linux (and Windows?)
Date: 
Message-ID: <m2y8q88cjy.fsf@david-steuber.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> > AFAIK MS is turning on similar functionality in the next WinXP
> > service pack, though I don't know the details (tinfoil hat: and in
> > MS's case, no doubt it's an evil plot to introduce some part of
> > their "treacherous computing" framework quietly.)
> 
> Turns out it is evil -- it doesn't apply to the .NET runtime.  Which
> might be okay, if .NET didn't have a history of security holes.  So,
> Java, Smalltalk, and Lisp, apps will suddenly stop working.  Yuck.
> You can't uninstall those things, can you?

How does this work?  Does .NET make a secret API call that says, "go
ahead.  You can trust me."?  Does this mean that everything that is
not built for .NET stops working?

Sounds like DR-DOS and Netscape all over again.

-- 
Those who do not remember the history of Lisp are doomed to repeat it,
badly.

> (dwim x)
NIL
From: Brian Downing
Subject: Re: gcl-2.6.1 on Fedora Core? - non-exec stack on Linux (and Windows?)
Date: 
Message-ID: <n2K3c.517206$I06.5834331@attbi_s01>
In article <··················@news.indigo.ie>,
David Golden  <············@oceanfree.net> wrote:
> This probably bites several other Lisps too, not to mention loads of other
> non-lisp non-C stuff.  There are fairly good reasons for the change, all
> the same, though they mostly stem from C sucking, I guess.

In addition to the non-executable stack, I bet the "load libraries and
executables at a random location" aspect of this will make finding
contiguous memory locations for the Lisp heap a lot of fun too.

(Hopefully if you feed mmap a desired address it doesn't just blatantly
ignore it - I'm not sure how anything terribly interesting would work
then.)

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net>