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