View Issue Details

IDProjectCategoryView StatusLast Update
0011563FPCCompilerpublic2009-03-20 13:04
ReporterHarald van Dijk Assigned ToJonas Maebe  
Status closedResolutionfixed 
Product Version2.2.0 
Target Version2.4.0Fixed in Version2.4.0 
Summary0011563: fpc-generated object files are marked as requiring executable stacks
DescriptionPrograms such as

program ExecStack;
  procedure DoIt;
    proc = procedure;
    ret: Byte;
    DoNothing: proc;
    ret := $C3;
    DoNothing := proc(@ret);

should be made to segfault, as the GNU tools do for the corresponding C program. Code rarely needs to be placed on the stack, and it should be disallowed unless specifically requested. GNU/Linux systems default to marking the stack as executable, and let programs specify they don't need it. GNU's linker does this if all of _its_ input files say they do not need code on the stack. fpc-generated object files don't say so, even though they don't need it.
Additional InformationObject files can specify they don't need an executable stack, and when using gas, this can be done by placing

.section .note.GNU-stack,"",%progbits

at the end of the assembly file. You can wrap the above in

#if defined(__linux__) && defined(__ELF__)

to minimise changes on other systems, or you can move the check in fpc itself.

The same change needs to be made when fpc writes object files directly, too, and there


in TElfObjectOutput.writedata can be used, possibly again with a check that an object file for Linux is generated.

Aside from that, fpc sources include some assembly files, which would need to be modified directly the way mentioned above. With all that changed, the ExecStack program aborts with runtime error 216, which is exactly what I'm hoping to see. And a Linux livecd from as early as February 2000 has no problems running correct programs generated by a modified fpc, so there should be no backwards compatibility concerns.

For more info:

A possible problem is that some software written in FreePascal may directly choose to place code on the stack, similar to what I was told Lazarus used to do on the heap. To satisfy these programs, a compiler option can be added so that fpc continues to generate object files the way it does now, and the programs continue to work as they used to.
TagsNo tags attached.
Fixed in Revision12356
Attached Files


related to 0018414 closedJonas Maebe Lazarus executable is marked as 'stackexecute' again. 


Tomas Bzatek

2008-07-31 11:23

reporter   ~0021012

Executable stack in FreePascal-compiled programs is causing SELinux AVC denials in default unconfined context, resulting in non-working threads (cthreads unit). This is a serious issue.


2008-07-31 15:17

administrator   ~0021016

I checked executables on several linuxes and none had a .note.GNU-stack section. Doing it through a switch is not possible because the switch cannot influence assembler files. What happens if you pass "-k-z noexecstack" to fpc?

Tomas Bzatek

2008-08-14 17:24

reporter   ~0021338

After adding the "-k-z noexecstack" I get an compiled executable which refuses to execute (tried to compile with -We and without it):

-bash: ./tuxcmd: /usr/lib/ bad ELF interpreter: No such file or directory

My application uses a lot of exotic units - glib2, gtk2, cthreads, libc (exhaustive use), syncobjs - no Lazarus units though. Do you have any tip what to watch for, what might be the cause of needing executable stack?

Oh btw., using FPC 2.2.1 [2008/05/14] on i386, no success with 2.2.0 release either.

Jonas Maebe

2008-08-16 13:15

manager   ~0021395

Last edited: 2008-08-16 13:17

That error message has nothing to do with requiring an executable stack (and FPC programs do not need one). It means that the dynamic linker is set wrongly in the executable for some reason.

Edit: or maybe that it's set wrongly in your /usr/lib/, I don't know for sure (if that file doesn't exist, it's in the executable)


2008-09-04 11:40

reporter   ~0021983

Same problem here. I wrote a Gentoo ebuild for an FPC program. During the installation phase of the package, portage displays the following message:

 * QA Notice: The following files contain executable stacks
 * Files with executable stacks will not work properly (or at all!)
 * on some architectures/operating systems. A bug should be filed
 * at to make sure the file is fixed.
 * For more information, see
 * Please include this file in your report:
 * /var/tmp/portage/games-arcade/ultrastardx-1.1_alpha/temp/scanelf-execstack.log
 * RWX --- --- usr/games/bin/ultrastardx

A "scanelf -e ultrastardx" gives:
ET_EXEC RWX R-- RW- ultrastardx

I tested a simple "hello world" program and it uses no executable stack:

ET_EXEC --- --- RW- fpctest
ET_REL !WX --- --- fpctest.o

After just adding cthreads to the uses section, the stack exec-flag is set:

ET_EXEC RWX R-- RW- fpctest
ET_REL !WX --- --- fpctest.o

The "-z noexecstack" option works for me but instead of -k-z noexecstack it must be -k"-z noexecstack" otherwise the program cannot be executed. Similar to Thomas Bzatek's "bad ELF interpreter" error with -k-z noexecstack I get the follwing error:
  bash: ./ultrastardx: No such file or directory

Probably because only -z is passed to the linker without the noexecstack parameter.
With -k"-z noexecstack" scanelf output is:
ET_EXEC RW- R-- RW- ultrastardx

and the program starts again. So this workaround might be applicable until the FPC assembler files in rtl/linux/i386, x86_64, etc. are fixed.

Tomas Bzatek

2008-10-07 15:36

reporter   ~0022640

OK, my problem is gone, I had malformed command line passed to compiler. The "-k-z noexecstack" as one argument is working fine, no SELinux AVC denials anymore.

It's worth noting that execstack(8) does similar job.

Marco van de Voort

2008-10-07 16:16

manager   ~0022641

Last edited: 2008-10-07 16:32

Note that you can probably put the -k"-z noexecstack" on a separate file in your fpc.cfg (e.g. in some post install event in the Gentoo port/package) to fix this current release cycle.

Do I read it correctly if I see that the scan program (second attempt, with cthreads) points to the fpctest.o object file as the culprit? That's a bit strange since that doesn't contain the the startup code, but only the pascal main module.

Ah, ok, so each object needs to have this section apparantly, at least on Linux.


2008-12-13 11:50

administrator   ~0023813

Shouldn't we integrate this into the compiler by creating appropriate sections? I consider -k"-z noexecstack" only as a workaround.

Jonas Maebe

2008-12-13 11:57

manager   ~0023816

> Shouldn't we integrate this into the compiler by creating appropriate sections?

That's what I did.


2008-12-13 12:16

administrator   ~0023818

Ops, I missed this :)

Issue History

Date Modified Username Field Change
2008-06-26 22:17 Harald van Dijk New Issue
2008-07-31 11:23 Tomas Bzatek Note Added: 0021012
2008-07-31 15:17 Florian Note Added: 0021016
2008-08-14 17:24 Tomas Bzatek Note Added: 0021338
2008-08-16 13:15 Jonas Maebe Note Added: 0021395
2008-08-16 13:17 Jonas Maebe Note Edited: 0021395
2008-09-04 11:40 hennymcc Note Added: 0021983
2008-10-07 15:36 Tomas Bzatek Note Added: 0022640
2008-10-07 16:16 Marco van de Voort Note Added: 0022641
2008-10-07 16:32 Marco van de Voort Note Edited: 0022641
2008-12-12 16:43 Jonas Maebe Status new => assigned
2008-12-12 16:43 Jonas Maebe Assigned To => Jonas Maebe
2008-12-12 17:26 Jonas Maebe Fixed in Revision => 12356
2008-12-12 17:26 Jonas Maebe Status assigned => resolved
2008-12-12 17:26 Jonas Maebe Fixed in Version => 2.3.1
2008-12-12 17:26 Jonas Maebe Resolution open => fixed
2008-12-12 17:26 Jonas Maebe Target Version => 2.4.0
2008-12-13 11:50 Florian Note Added: 0023813
2008-12-13 11:57 Jonas Maebe Note Added: 0023816
2008-12-13 12:16 Florian Note Added: 0023818
2009-03-20 13:04 Jonas Maebe Status resolved => closed
2011-01-06 13:50 Joost van der Sluis Relationship added related to 0018414