[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 2.0.0.23 (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:
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!
- [Tinycc-devel] lib/alloca*: mark ELF stack access flags as nonexecutable, grischka, 2011/01/05
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, Sergei Trofimovich, 2011/01/05
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable,
grischka <=
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, Sergei Trofimovich, 2011/01/06
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, grischka, 2011/01/06
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, Sergei Trofimovich, 2011/01/06
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, grischka, 2011/01/06
- [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable, Sergei Trofimovich, 2011/01/06