tinycc-devel
[Top][All Lists]
Advanced

[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: Fri, 7 Jan 2011 00:20:42 +0200

On Thu, 06 Jan 2011 22:03:31 +0100
grischka <address@hidden> wrote:

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

Sorry, My wording was not precise. I meant tcc generates not execstack,
but default stack (which is the same on vanilla kernel).

As flags on stack are default (AFAIU there no such ones in usual ELF at all,
so it's up to the system to pick them). PAX picks 'rw' for stack accessible
(while vanilla linux picks 'rwx' for stack). So everything runs fine (until you 
try
to run stuff on stack). I checked normal case too to make sure.

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

It seems default 'rwx' stack is a linux's  ABI set in stone decades ago. Yeah,
not nice default. Maybe, it will change some day at least for amd64. Now glibc
has to fix it on every program startup depending on GNU_STACK header
presence which gcc emits for all C programs by default (but not assembler ones).

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature


reply via email to

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