From owner-freebsd-bugs@freebsd.org Thu Aug 22 13:36:10 2019 Return-Path: <owner-freebsd-bugs@freebsd.org> Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6FE1BC94D8 for <freebsd-bugs@mailman.nyi.freebsd.org>; Thu, 22 Aug 2019 13:36:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46Dlt22NGdz4T2d for <freebsd-bugs@freebsd.org>; Thu, 22 Aug 2019 13:36:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 518DFC94D7; Thu, 22 Aug 2019 13:36:10 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 51527C94D6 for <bugs@mailman.nyi.freebsd.org>; Thu, 22 Aug 2019 13:36:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Dlt21TYyz4T2b for <bugs@FreeBSD.org>; Thu, 22 Aug 2019 13:36:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F1F4E4EC7 for <bugs@FreeBSD.org>; Thu, 22 Aug 2019 13:36:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7MDa9YP031085 for <bugs@FreeBSD.org>; Thu, 22 Aug 2019 13:36:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7MDa9Zf031084 for bugs@FreeBSD.org; Thu, 22 Aug 2019 13:36:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 239894] security.bsd.stack_guard_page default causes Java to crash Date: Thu, 22 Aug 2019 13:36:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kurt@intricatesoftware.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports <freebsd-bugs.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-bugs>, <mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs/> List-Post: <mailto:freebsd-bugs@freebsd.org> List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-bugs>, <mailto:freebsd-bugs-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 13:36:10 -0000 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.=