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

[grischka]

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:
> >
> >    
> > http://repo.or.cz/w/tinycc.git/commitdiff/d97a25fbdd80ad005be41e9d47d6aefe2a5f6cae
>
> 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:
>
>     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).

How does tcc violate that stack policy?

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

Unlikely.

> > 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).

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 
> didn't
>    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 };
        ((void(*)(void))xxx)();
        return 0;
    }

--- grischka

> Thanks!