[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] [Re: Executable memory: further programs that fail]
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] [Re: Executable memory: further programs that fail] |
Date: |
01 Dec 2003 17:47:19 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! Tim, the -Wa,--execstack option is trivial to implement
and is sure to work. It would be nice to have a configure test to
determine when it is necessary, but all gcc I have available seem to
take the option. Even though it is not the desirable long term option
as the poster states, a final solution must await a fix to emacs'
unexec, at which point we can move DBEGIN to an internal variable, and
test if holes are permitted in the heap. So at this point I recommend
punting and disabling exec-shield until a work-around for unexec is at
hand. Your thoughts?
Take care,
Tim Daly <address@hidden> writes:
> Some hints from the Fedora Core mailing list about making programs
> run under exec-shield.
>
> Tim
>
> From: Ingo Molnar <address@hidden>
> Subject: Re: Executable memory: further programs that fail
> To: Fedora Development <address@hidden>
> Date: Mon, 24 Nov 2003 05:42:27 -0500 (EST)
>
>
> On Sat, 22 Nov 2003, Gerard Milmeister wrote:
>
> > So is it alright to include in Fedora packages that require exec-shield
> > to be turned off? Should there be a wrapper-script that calls the main
> > executable with 'setarch'?
>
> all 'third party' apps will run with exec-shield disabled by default.
>
> _Iff_ a package is recompiled under Fedora (using Fedora's gcc and
> binutils) then you might end up with an app that has exec-shield enabled
> although the app itself for whatever reason has some executability
> assumption.
>
> In this case there are myriads of ways to make the app work again:
>
> - use 'setarch i386 <app>' [or rather, use the 'i386 <app>' shortcut]
>
> - add this gcc option to the CFLAGS in the Makefile:
>
> -Wa,--execstack
>
> - add the following oneliner anywhere in the app's source in an assembly
> file to disable exec-shield:
>
> .section .note.GNU-stack, "x", @progbits; .previous
>
> - disable exec-shield globally, put "kernel.exec-shield = 0" into
> /etc/sysctl.conf.
>
> - the preferred solution: fix the app itself to not assume executability
> of non-executable regions or not hardcode any VM properties such as
> 'mmaps start at 2 GB'. Both assumptions are illegal and these apps will
> likely break on 64-bit architectures too, so they should be fixed. Note
> that typically the changes needed are quite simple.
>
> in any case, please keep reporting apps that need an executable stack, we
> want to track them all down and fix them for good. Fortunately 99.9% of
> the 5000+ binaries in a full Fedora Core 1 install work out of box.
>
> note that there are also prelink related problems, which we want to know
> about and fix just as much, but which should not be confused with
> exec-shield problems. Sometimes these do get mixed up.
>
> (in any case, please also read the extensive description provided by
> Roland McGrath's "exec-shield mmap & brk randomization" email.)
>
> Ingo
>
>
> - --
> fedora-devel-list mailing list
> address@hidden
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> ----------
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: [Gcl-devel] [Re: Executable memory: further programs that fail],
Camm Maguire <=