[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: grischka
Subject: [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable
Date: Thu, 06 Jan 2011 19:38:36 +0100
User-agent: Thunderbird (Windows/20090812)

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

HI Sergei,

Could you tell something about your patch here:


Hello grischka!

I should be more verbose in the commit message.

Yes please ;)

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

How does tcc violate that stack policy?

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 

No, gcc does not link alloca86*.o into the tcc binary.  Those files
are exclusively to support binaries generated by tcc.

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.

A section named ".note.GNU-stack" has no special meaning to tcc's
built-in linker.

Does that explanations sound good enough to keen this change?

Well, it sounds like the change would improve security.  Does it?

Aside from that, would this code, compiled with gcc or tcc, run on
your "hardened" system?

    int main()
        char xxx[] = { 0xc3 };
        return 0;

--- grischka


reply via email to

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