https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
Bug ID: 239894
Summary: security.bsd.stack_guard_page default causes Java to
crash
Product: Base System
Version: 12.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: gle...@freebsd.org
The default setting of the security.bsd.stack_guard_page sysctl on FreeBSD
causes issues for Java thread stack handling.
The most obvious of these is bug #222146 - a Java program which includes
infinite recursion will crash rather than throwing StackOverflowError. While
there is a workaround, the workaround is fragile and causes other issues.
A fairly lengthy discussion of the problem from the Java side can be found
here:
https://github.com/battleblow/openjdk-jdk11u/issues/51
Briefly, Java attempts to create its own guard pages in the thread stack, but
when security.bsd.stack_guard_page is non-zero (by default it is 1), there is
an extra guard page which the JVM doesn't anticipate. This causes SIGSEGV
fault addresses to be outside the JVM guard region, meaning that the JVM
crashes rather than handling the signal as a StackOverflowError.
The initial naive workarounds discussed (the first of which is still in the
ports tree) centre around adjusting for the extra default page of guard. These
are fragile for a couple of reasons. The obvious one is that the sysctl can be
a different value than the default, in which case the workaround is wrong.
This is easy enough to adjust to be reading the value, but that is still
fragile since the value can change while the program is running (there are
potential additional complications in the pthread library potentially caching
stacks as well). The other problem this causes is that the JVM will use some
of its guard region (the reserved region) to allow critical sections to
complete so that data is not left in an inconsistent state when a
StackOverflowError is thrown. You can read about that at
https://openjdk.java.net/jeps/270. This facility is completely circumvented by
the automated guard page(s) put in place by the kernel since the JVM can't
remove the protection on them.
Given that, the only reliable "fix" that works for all the Java functionality
is to remove the current workaround from the ports tree and instruct users to
set the value of the sysctl to zero. This is not a great solution for a couple
of reasons, since Java is broken by default, and the fix is to remove
protection put in place due to the Stack Clash vulnerability.
This bug is basically a request to see if there are any suggestions from the
kernel developer side as to how we can have both a fully functional version of
Java and the sysctl default still in place.
Note that despite the FreeBSD version selection above, this affects all FreeBSD
versions and architectures since
https://svnweb.freebsd.org/base?view=revision&revision=320317
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
