From owner-freebsd-stable@freebsd.org Tue Sep 10 16:50:41 2019 Return-Path: Delivered-To: freebsd-stable@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 C454DDC481 for ; Tue, 10 Sep 2019 16:50:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46SWHj2k4Wz3BtC for ; Tue, 10 Sep 2019 16:50:41 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1568134240; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=gvnG6Bp/p6GR0mFZ8vQTrS9sNudJo+v5ULnNO+rJBHokVevRLRHDTPfTwc4iFSs0Q5pNRPlqUF+H7 niNCXpPbwJARChLgKJefslQq7YTYgtKoH3mDdvMj8Clb8Qx1LtNL5txMpE7TUbanazy38TL1Wvl+fe lVbhTgAsoU3fyNhAuiUw8ejRkCnDbNKS6bS8ifc/bIgRYIJ0xkmGGuFRnYgJvAJbg+cfYEK9yaSegI VzN0zMQsg2qjECO2b0PzLFb0MJvu9dlSAY6j/wTwjrhyy3j1qhkNXUMfTLEw7ICoCf+bbwN8AlHDBK 0myiVLUXNu8ynJrYk2wS6VVmb7Y7w5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=ZlYpiz+4MGkzk5WNE4BSwVf1O4qRDdTa8AbgatbvI7w=; b=gDnhu0vggvg+JMngdvWbk+IhFiObGIPccRpa14tT00TFobtQqx7GfHDtmtVHfD23oGbALMPTZw241 iaPqyWSSPLRyTPMry9OP9zatIkZ3HdXGBPjJB/IZ4lTUwmIz4tIi3skfNdV97kn0ilhWdMzo97KfLx PRJ5SqRwpLAMBSBPDW1J3zZCMPo9WXDDIbAX1s36TnCLundHNBh327+fsx3vj94v/UYfEHKoVQRJO9 rZ7VHcVzl5ZmbtAz41/zwlDExuU91aNWb+flVp1ecEpRfoYsObyjqLJP6ebrxvJ2TrCSxsBdJMk/pb Nbh85aXGDR3ef2Dqxjuihh+BDygH5yA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=ZlYpiz+4MGkzk5WNE4BSwVf1O4qRDdTa8AbgatbvI7w=; b=RFAueI6EqpyqX/8bsITyPiVanfZj1oHF2VBLYMgiXk4guIcvemRaheeEOlQhwZT13VRTtDzRZFHnb uU3FqRYjOYfjp2hbO+sHSipJoG/aGs5fYph9+6h31sLaOTlNS8VUUxUTjq8qQu/KvaF/q4VmgPZFC/ lJUub2QcCtMVejqeKEoe+pnhL6RMgBZZMmfW9XkbVLZ7RtYwFXGVLAEmFM+d+icdvRqt39XsXIzBgs ZlhLYAJ/3bmgePrrlFMP4V/CSvNSQQOpcFxLxieOC+WNVdInHcdcdIovkqWNKOBBy16k+yhTsJ/0uW tBksz8DDdLWE5zXfbunXI4ImdZp59Pw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1bb0dcfe-d3eb-11e9-85ed-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 1bb0dcfe-d3eb-11e9-85ed-13b9aae3a1d2; Tue, 10 Sep 2019 16:50:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x8AGoXCU067287; Tue, 10 Sep 2019 10:50:33 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <2a0ad34a5c57489732296e43d50b42b5f3923f96.camel@freebsd.org> Subject: Re: ntpd doesn't like ASLR on stable/12 post-r350672 From: Ian Lepore To: Konstantin Belousov , Trond =?ISO-8859-1?Q?Endrest=F8l?= Cc: emaste@freebsd.org, freebsd-stable@freebsd.org Date: Tue, 10 Sep 2019 10:50:33 -0600 In-Reply-To: <20190825120342.GN71821@kib.kiev.ua> References: <20190824204114.GG71821@kib.kiev.ua> <20190824222817.GJ71821@kib.kiev.ua> <20190825120342.GN71821@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46SWHj2k4Wz3BtC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 16:50:41 -0000 On Sun, 2019-08-25 at 15:03 +0300, Konstantin Belousov wrote: > On Sun, Aug 25, 2019 at 12:40:22AM +0200, Trond Endrestøl wrote: > > On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote: > > > > > On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote: > > > > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote: > > > > > > I tried changing command="/usr/sbin/${name}" to > > > > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in > > > > > > /etc/rc.d/ntpd, but that didn't go well. > > > > > > > > > > If you set kern.elf64.aslr.stack_gap to zero, does it help ? > > > > > > > > That helped. Thank you again. > > > > > > Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread, > > > and if yes, what this new limit is ? > > > > (gdb) > > 5265 if (-1 == setrlimit(RLIMIT_STACK, &rl)) { > > (gdb) print rl > > $1 = {rlim_cur = 204800, rlim_max = 536870912} > > So they set the stack limit to 200K, am I right ? I suspect they do > that because ntpd wires entire process address space, so 512M blows off > all limits on wiring. > > I do not have a good idea how to make this behaviour compatible with > the gap. Might be we can change the gap sizing parameter to KBs instead > of percentage, and set the defaults in 64KB range. > > > > > > aslr.stack_gap is the percentage for the gap on that stack, and since > > > default size of the main stack limit is quite large 512M, even 3% > > > (default gap upper limit) are whole 15M. If the new limit is less than > > > 15M, there is a likely probability that only the gap is left after the > > > rlimit(2) call, leaving no space for the program frames. > > > > > > At least this looks like a nice theory. So is the problem here that before ntpd is running and has the chance to call setrlimit(), aslr has already created a large stack gap? If so, it seems to me that aslr and setrlimit(RLIMIT_STACK, ...) are never going to work right together. Even if the default stack gap were much smaller, code using RLIMIT_STACK is going to end up with a stack smaller than it asked for because the gap it has no way of knowing about uses up some part (or all of) the limited space. If the default gap were 64K or less, things would be much more likely to work accidentally (and we might never have noticed this situtation), but they still wouldn't be working correctly. Is it possible for the code on the kernel side to add the requested limit to the gap size to generate a result that gives the caller the usable stack size they asked for? -- Ian