From owner-svn-src-head@freebsd.org Thu Jul 6 22:45:38 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAC4DD93D86 for ; Thu, 6 Jul 2017 22:45:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B13D82B07 for ; Thu, 6 Jul 2017 22:45:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24435 invoked from network); 6 Jul 2017 22:40:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Jul 2017 22:40:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 06 Jul 2017 18:38:56 -0400 (EDT) Received: (qmail 13253 invoked from network); 6 Jul 2017 22:38:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jul 2017 22:38:56 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 57FD5EC8FBA; Thu, 6 Jul 2017 15:38:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r320674 - head/usr.sbin/bsdinstall/scripts Message-Id: <9691CBDC-9C55-4E05-AFA2-9FEFD5E1B21F@dsl-only.net> Date: Thu, 6 Jul 2017 15:38:54 -0700 To: Konstantin Belousov , robak@FreeBSD.org, svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 22:45:38 -0000 The following is only offered as a possibility for where the 2MB idea might have came from: https://hardenedbsd.org . I make no claim that the script change is in fact appropriate: I've not studied the issue. Quoting https://hardenedbsd.org "Stack Clash Mitigations" dated = 2017-Jun-25: FreeBSD provides a stack guard implementation, but has it disabled by = default. As discussed in the Qualys report, when enabled, FreeBSD's = stack guard implementation had a logic flaw that prevented it from being = effective. A proof-of-concept exploit written by HardenedBSD's own Shawn = Webb demonstrated Qualys' claims. HardenedBSD had the stack guard = enabled by default. To mitigate Stack Clash, we in HardenedBSD performed the following in = 12-CURRENT over the week of 19 Jun 2017 to 24 Jun 2017: =E2=80=A2 Fixed the flaw in the stack guard implementation that = prevented it from being effective. =E2=80=A2 Increased the size of the stack guard from one 4KB = page to 2MB. =E2=80=A2 Prevented mappings from occurring between the = bottom-most limit of the stack and the top of the stack. =E2=80=A2 (Soon) Modified the per-thread stack guard in libthr = to be of random size, minimum 1MB, maximum 5MB. =E2=80=A2 This also randomizes the top-most address of = each per-thread stack. The commits for these changes have been backported to HardenedBSD = 11-STABLE. Item #1 has been backported to HardenedBSD 10-STABLE. On 24 Jun 2017, FreeBSD committed their Stack Clash mitigation. It = introduces the concept of MAP_GUARD, which is a special PROT_NONE = mapping. It's placed immediately below the bottom-most limit of the = stack. It's a really innovative implementation that allows general use = of guard pages. Indeed, in a follow-up commit, the RTLD now uses = MAP_GUARD for guard pages between shared objects. FreeBSD's stack guard = is still a single 4KB page in size, even with Qualys' recommendation to = use a minimum of 1MB. On 25 Jun 2017, FreeBSD followed up with a commit = to fix a regression that effectively disabled the stack guard in certain = edge cases with the new implementation. Overall, FreeBSD's solution to = the Stack Clash problem is innovative and even useful outside the = context of Stack Clash. We in HardenedBSD now use a hybrid of both approaches. We've hardened = the security.bsd.stack_guard_page sysctl node to a 2MB stack guard. = We've made that sysctl node a read-only tunable, configurable only at = boot-time. The changes to libthr still stand and the per-thread stack = guard size is a random size between 1MB and 5MB. We may look to = integrate MAP_GUARD with libthr instead of its reliance on = mprotect(PROT_NONE). Update 25 Jun 2017: The randomization of the per-thread stack guard has = been found to be too aggressive. We are investigating this feature and = will revisit it soon. =3D=3D=3D Mark Millard markmi at dsl-only.net