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

[Sergei Trofimovich]

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:

    http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

> 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:

    http://pax.grsecurity.net/docs/mprotect.txt

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 
system
violating nonexecutable stack policy (Gentoo has an automatic checker for such
packages).

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 
AFAIU),
   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 
EXECSTACK).

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

Does that explanations sound good enough to keen this change?

Thanks!

-- 

  Sergei

signature.asc
Description: PGP signature