RFR (S) 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL)
David Simms
david.simms at oracle.com
Mon Sep 2 05:37:50 PDT 2013
Hi,
Thanks for looking at this, reply inline...
On 02/09/13 13:57, Florian Weimer wrote:
> On 09/02/2013 01:18 PM, David Simms wrote:
>> G'day all,
>>
>> Please review a small enhancement for working around a rare but annoying
>> Linux bug (ia32 only).
>>
>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8023956 (
>> http://bugs.sun.com/view_bug.do?bug_id=8023956)
>>
>> Webrev: http://cr.openjdk.java.net/~dsimms/8023956/
>> <http://cr.openjdk.java.net/%7Edsimms/8023956/>
>
> This needs at least a compiler barrier between the write and the
> function call:
>
> + // Some code to exec: the 'ret' instruction
> + codebuf[0] = 0xC3;
> +
> + // Call it and ret
> + void (*fn)(void) = (void (*)(void)) codebuf;
> + fn();
>
Noted, originally used __asm__ volatile("call..."), but this was more
readable. It is specific to IA32, tested and it's works for the
optimized compile.
> Not sure if a memory barrier is needed as well.
>
> + munmap(codebuf, page_size);
>
> I assume the implicit assumption here is that the CS limit is not
> rolled back due to this call (and it makes this whole exercise a NOP
> on NX-capable hardware).
You've got a point there, I'll need to hold the page over. Patch updated.
>
> + * Work-around for broken NX emulation using CS limit, RedHat patch
> "Exec-Shield"
>
> It's spelled "Red Hat". :-)
>
Sorry about that.
> Do you have reproducer for this problem? I'm surprised we haven't got
> something similar in IcedTea.
>
It's a really small race condition with MM invalidation on SMP, my repro
(based on ) looks like this:
* v8 benchmarks from
http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks
* Repeatedly run: $JDK8_EA_i586/bin/java -XX:MaxNodeLimit=300000
-XX:+BackgroundCompilation -XX:+TieredCompilation
-XX:+PrintCodeCache -jar
/java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar
run.js
I happened to get lucky and found I could reproduce inside a VirtualBox
using Ubuntu 10.04 desktop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130902/8cf119a5/attachment-0001.html
More information about the hotspot-runtime-dev
mailing list