Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Aug 2019 15:54:53 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 239894] security.bsd.stack_guard_page default causes Java to crash
Message-ID:  <bug-239894-227-UI8TUt0ccK@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-239894-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-239894-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239894

--- Comment #9 from Kurt Miller <kurt@intricatesoftware.com> ---
(In reply to Konstantin Belousov from comment #7)

Answering your questions:
Attempting execute code on the stack I believe with raise a SIGSEGV.

The JVM uses pthread stacks.

Currently the jvm does an mmap(MAP_ANON) before an mprotect(PROT_NONE) on t=
he
Hotspot Guard pages at the end of the stack as reported by
pthread_attr_getstack(). On 13-current, the kernel moves the kernel managed
guard page as follows:

   Low memory addresses
    +------------------------+
    |                        |\  Java thread created by VM does not have
    |   pthread guard page   | - pthread guard, attached Java thread usually
    |                        |/  has 1 pthread guard page.
 P1 +------------------------+ Thread::stack_base() - Thread::stack_size()
    |                        |\
    |  HotSpot Guard Pages   | - red, yellow and reserved pages
    |                        |/
    +------------------------+ JavaThread::stack_reserved_zone_base()
    |                        |\
    |   kernel guard page(s) | - This page is the problem
    |                        |/
    +------------------------+ JavaThread::stack_reserved_zone_base()
    |                        |\
    |      Normal Stack      | -
    |                        |/
 P2 +------------------------+ Thread::stack_base()


The kernel managed guard page follows the HotSpot Guard pages which poses t=
wo
problems.=20

1) SIGSEGV raised before hitting the HotSpot Guard Pages (executing code on
stack?)

2) The inability to change the protection on the kernel guard pages so that=
 the
thread that hit it can be allowed to temporarily use that space so it can
unwind safely.

Please see test program for this case in this comment:

https://github.com/battleblow/openjdk-jdk11u/issues/51#issuecomment-5206029=
73

I encourage you to look at this issue from the perspective of the issues in
libthr I outlined in comment #1 instead of from the JVM's needs. If the iss=
ues
in libthr are corrected, it is very likely that the JVM can use the same
approach as libthr to place guard pages at the end of the stack.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239894-227-UI8TUt0ccK>