Unrecoverable stack overflow due to missing guard pages

[Vitaly Davidovich]

Hi all,

Noticed this bug report: https://bugs.openjdk.java.net/browse/JDK-7107135

However, it appears that even with 7u60 this same problem occurs. Is that
fix supposed to work if a dependent native lib (.so on linux) has an
executable stack flag set? The case I'm seeing is just like that: a JNI
call is made to a native library whose ELF stack is not executable, but a
dependent lib does have that flag set.

The fix associated with the above bug report appears to detect such a lib
being loaded but only directly (I.e. via System.loadLibrary). Is that
correct? Also, is there anything planned to attempt to handle this for
indirectly loaded libs?

Thanks

Sent from my phone

[Dmitry Samersoff]

Vitaly,

1. If one of dependent DSO has executable stack this patch will not work
and hotspot would have a problem.

2. I don't see any good way to handle it on hotspot side.

3. Personally, I think that this situation have to be addressed on
OS/DSO vendor side, because executable stack is a huge security whole.

-Dmitry

Post by Vitaly Davidovich
Hi all,
Noticed this bug report: https://bugs.openjdk.java.net/browse/JDK-7107135
However, it appears that even with 7u60 this same problem occurs. Is that
fix supposed to work if a dependent native lib (.so on linux) has an
executable stack flag set? The case I'm seeing is just like that: a JNI
call is made to a native library whose ELF stack is not executable, but a
dependent lib does have that flag set.
The fix associated with the above bug report appears to detect such a lib
being loaded but only directly (I.e. via System.loadLibrary). Is that
correct? Also, is there anything planned to attempt to handle this for
indirectly loaded libs?
Thanks
Sent from my phone

[Vitaly Davidovich]

Hi Dmitry,

Thanks for replying. I agree with your points - simply wanted to double
check my understanding of the issue and the patch. This has nasty
consequences for the JVM, unfortunately, but yeah, I don't see any
foolproof way to fix it at the VM layer.

Thanks

Sent from my phone
On Sep 27, 2014 3:07 AM, "Dmitry Samersoff" <dmitry.samersoff at oracle.com>

Post by Dmitry Samersoff
Vitaly,
1. If one of dependent DSO has executable stack this patch will not work
and hotspot would have a problem.
2. I don't see any good way to handle it on hotspot side.
3. Personally, I think that this situation have to be addressed on
OS/DSO vendor side, because executable stack is a huge security whole.
-Dmitry

Post by Vitaly Davidovich
Hi all,

https://bugs.openjdk.java.net/browse/JDK-7107135

Post by Vitaly Davidovich
However, it appears that even with 7u60 this same problem occurs. Is

that

Post by Vitaly Davidovich
fix supposed to work if a dependent native lib (.so on linux) has an
executable stack flag set? The case I'm seeing is just like that: a JNI
call is made to a native library whose ELF stack is not executable, but a
dependent lib does have that flag set.
The fix associated with the above bug report appears to detect such a lib
being loaded but only directly (I.e. via System.loadLibrary). Is that
correct? Also, is there anything planned to attempt to handle this for
indirectly loaded libs?
Thanks
Sent from my phone

--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.