--- a/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Mon Sep 23 08:56:19 2013 -0700
+++ b/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Wed Sep 25 13:58:13 2013 +0200
@@ -876,3 +876,46 @@
#endif
}
#endif
+
+
+/*
+ * IA32 only: execute code at a high address in case buggy NX emulation is present. I.e. avoid CS limit
+ * updates (JDK-8023956).
+ */
+void os::workaround_expand_exec_shield_cs_limit() {
+#if defined(IA32)
+ size_t page_size = os::vm_page_size();
+ /*
+ * Take the highest VA the OS will give us and exec
+ *
+ * Although using -(pagesz) as mmap hint works on newer kernel as you would
+ * think, older variants affected by this work-around don't (search forward only).
+ *
+ * On the affected distributions, we understand the memory layout to be:
+ *
+ * TASK_LIMIT= 3G, main stack base close to TASK_LIMT.
+ *
+ * A few pages south main stack will do it.
+ *
+ * If we are embedded in an app other than launcher (initial != main stack),
+ * we don't have much control or understanding of the address space, just let it slide.
+ */
+ char* hint = (char*) (Linux::initial_thread_stack_bottom() -
+ ((StackYellowPages + StackRedPages + 1) * page_size));
+ char* codebuf = os::reserve_memory(page_size, hint);
+ if ( (codebuf == NULL) || (!os::commit_memory(codebuf, page_size, true)) ) {
+ return; // No matter, we tried, best effort.
+ }
+ if (PrintMiscellaneous && (Verbose || WizardMode)) {
+ tty->print_cr("[CS limit NX emulation work-around, exec code at: %p]", codebuf);
+ }
+
+ // Some code to exec: the 'ret' instruction
+ codebuf[0] = 0xC3;
+
+ // Call the code in the codebuf
+ __asm__ volatile("call *%0" : : "r"(codebuf));
+
+ // keep the page mapped so CS limit isn't reduced.
+#endif
+}