Date: Thu, 22 Aug 2019 13:36:09 +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-7iSVkh1gYf@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 #13 from Kurt Miller <kurt@intricatesoftware.com> --- (In reply to Shawn Webb from comment #12) The authors of the Stack Clash advisory indicate a 4096 byte guard region is not difficult to jump over and avoid. Their recommendation is a 1MB guard region. Restricting the value at 1 leaves this issue unaddressed. https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt I think the security.bsd.stack_guard_page mechanism needs a hard look at ho= w it is implemented. I see the following problems with the current approach. The kernel placed guard pages are placed *within* the stack space requested= by mmap(MAP_STACK). This is the primary reason setting this value high causes = the issues I pointed out. Currently it not possible for libthr or the JVM to kn= ow the number of pages the kernel placed due to TOCTOU and since these pages a= re kernel placed, userland should not have to do this. The kernel placed guard region should be additional pages outside of the the requested stack size. mmap on top of a MAP_STACK region causes the kernel to move the kernel mana= ged guard pages into the stack region further. I believe it uses the current va= lue of security.bsd.stack_guard_page for that but would need to test this to be sure. Nevertheless, moving the kernel managed guard pages means mmap on top= of the MAP_STACK region as a precursor to using mprotect means that both libthr and the JVM do not have a way to set their guard pages predictably. The ker= nel circumvents this by placing additional guard pages that interfere with user= land guard pages as described in previous comments and test programs. Simply using mprotect on top of MAP_STACK pages currently fails to work as well. It appears that for this work the pages need to be previously accesse= d. IMO, to address the needs of system security and pthreads guard pages and t= he JVM some changes need to be made to make things work that consistent with h= ow mmap and mprotect are expected to work. At a minimum, kernel placed guard pages need to be additional pages that do not invade the space returned from mmap(MAP_STACK). Ideally mprotect on the usable MAP_STACK space would be ma= de to work. This is most straightforward way libthr and the JVM can place their guard pages and is consistent with how these interferences are generally expected to work. --=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-7iSVkh1gYf>