GNU_STACK ELF header

[Douglas Simon]

On Aug 27, 2010, at 10:40 PM, Dr Andrew John Hughes wrote:

> On 27 August 2010 21:17, Douglas Simon <doug.simon at oracle.com> wrote:
>> 
>> On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote:
>> 
>>> On 27 August 2010 16:31, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>>>> Interesting. Had not heard about this new Elf header.
>>>> 
>>>> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty
>>>> old.
>>>> 
>>>> 32bit:
>>>> gcc (GCC) 3.2.1-7a (J2SE release)
>>>> 
>>>> 64bit:
>>>> gcc (GCC) 3.2.2 (SuSE Linux)
>>>> 
>>>> For jdk7, we are using the gcc compiler provided with Fedora 9,  gcc 4.3.0
>>>> 
>>>> -kto
>>>> 
>>>> 
>>>> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote:
>>>> 
>>>>> As a result of stack overflow detection breaking in Maxine on Linux, I
>>>>> learnt about this ELF header. My experience is described here:
>>>>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities
>>>>> 
>>>>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being
>>>>> omitted from the HotSpot and JDK libraries and executables?
>>>>> 
>>>>> -Doug
>>>> 
>>>> 
>>> 
>>> This was discussed last year:
>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html
>>> and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch.
>>> 
>>> GCC 4.3 is the earliest version of GCC IcedTea has been built with, to
>>> my knowledge, rather than the latest.  I'm currently building with GCC
>>> 4.5.1.
>> 
>> 
>> If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something?
>> 
>> -Doug
>> 
>> 
> 
> I'm afraid I don't know the details, only that this patch means the VM
> no longer has executable stack.

This means that stack overflow detection is broken on IcedTea by a Java application that loads an 'executable-stack' native library. I submitted a test case in the following bug report:

https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/625820

I think the long term solution is to modify the __make_stacks_executable function in libc/nptl/allocatestack.c such that it only adds the PROT_EXEC bit to each thread's stack and leaves the current values for the PROT_READ and PROT_WRITE bits as is.

-Doug