[Bug 239894] security.bsd.stack_guard_page default causes Java to crash

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894

--- Comment #13 from Kurt Miller <kurt at 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 how 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 know
the number of pages the kernel placed due to TOCTOU and since these pages are
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 managed
guard pages into the stack region further. I believe it uses the current value
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 kernel
circumvents this by placing additional guard pages that interfere with userland
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 accessed.

IMO, to address the needs of system security and pthreads guard pages and the
JVM some changes need to be made to make things work that consistent with how
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 made
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.

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