https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #13 from Kurt Miller <k...@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. _______________________________________________ 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"
