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

[grischka]

Sergei Trofimovich wrote:
> > > > How does tcc violate that stack policy?
> > > It always generates execstack binaries (not fixed yet).
> > [...]
> >
> > > $ ./main.tcc 
> > > Killed
> > > PAX: terminating task: /tmp/z/main.tcc(main.tcc):17706, uid/euid: 1000/1000, 
> > > PC: 0000719781b5175f, SP: 0000719781b51748
> > However that would mean that tcc does NOT generate execstack binaries.
> > (Unless the reason for the crash is something else.)
>
> It does, but PAX kernel (a set of patches on top of vanilla kernel
>  http://pax.grsecurity.net/docs/) won't allow you to run (or operate
> suspiciously) a binary with any static or dynamic mapping of Writable
> and eXecutable bits enabled for _any_ vma to exist in kernel.

Are you saying that the PAX kernel refuses to run anything created
by tcc at all?

> For example if you will try to workaround page permissions  for mmap/mprotect 
> you'll get an
> error from syscall.
>
> I've posted 2 results:
>     hardened: fail/failone
> and
>     nonhardened(standard for most users): (fail/run) 
>
> Repasting nonhardened results:
> > On nonhardened box:
> > $ ./main.gcc
> > Segmentation fault
>
> > [sf] /tmp/z:./main.tcc 
> > [sf] /tmp/z: # ooops, needs to be fixed!
>
> Here we see execstack is on in tcc generated binary and off on gcc's one.

Well, tcc simply does not specify executable permissions for the stack
so it's neither "off" nor "on" really.

It is just that I have some doubts about a policy which has execstack
"on" by default in the system but then wants everybody to add ugly hacks
into applications to fix this.

But maybe that's just me.  Anyway, thanks for the info and links etc.

--- grischka