[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecut

From: Sergei Trofimovich
Subject: [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable
Date: Wed, 5 Jan 2011 22:29:11 +0200

On Wed, 05 Jan 2011 15:21:20 +0100
grischka <address@hidden> wrote:

> HI Sergei,
> Could you tell something about your patch here:
> http://repo.or.cz/w/tinycc.git/commitdiff/d97a25fbdd80ad005be41e9d47d6aefe2a5f6cae

Hello grischka!

I should be more verbose in the commit message.
Some generic notes about GNU_STACK bit in ELF format on linux platform
can be found here:


> What is the effect of this patch and why do we need it, and on
> what platform?

So far platform is linux-elf. Certain systems (PaX kernel for example)
can be tweaked to forbid running programs with memory segments allowed
for both executing and writing. OpenBSD calls that security defence as W^X,
PaX project calls it MPROTECT:


So my goal is to harden the project I use a little bit more. It might sound too
paranoid in respect to the compiler, but tcc is one of rare packages in my 
violating nonexecutable stack policy (Gentoo has an automatic checker for such

Is there any build/runtime problems? Maybe, it breaks on ancient binutils?

> And why only when using alloca?  What about other stack usage like
> {
>      char tmp[100];
>      ...

Here we have two cases:

1. If we are talking about the tcc binary (which links against alloca86*.o 
   built with gcc then gcc already does proper stack marking when generates code
   (until we try to use local functions or other funky things requiring 

2. If we are talking about binaries generated by tcc, then I don't know. I 
   look at the part, which is responsible for ELF header generation yet.

Does that explanations sound good enough to keen this change?




Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]