Date: Sun, 25 Aug 2019 00:19:43 +0200 (CEST) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= <trond.endrestol@ximalas.info> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: ntpd doesn't like ASLR on stable/12 post-r350672 Message-ID: <alpine.BSF.2.21.99999.352.1908250012580.6386@enterprise.ximalas.info> In-Reply-To: <20190824204114.GG71821@kib.kiev.ua> References: <alpine.BSF.2.21.99999.352.1908242135380.6386@enterprise.ximalas.info> <20190824204114.GG71821@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 10:04:49PM +0200, Trond Endrestøl wrote:
>
> > Disabling ASLR, kern.elf64.aslr.enable=0, before starting ntpd
> > manually is a workaround, but this is not viable in the long run.
>
> Why ?
I like to keep ALSR enabled in the hope that it actually achieves
something. You are right, I can disable it completely.
> > 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.
--
Trond.
From owner-freebsd-stable@freebsd.org Sat Aug 24 22:28:26 2019
Return-Path: <owner-freebsd-stable@freebsd.org>
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 A1BE4CCE9A
for <freebsd-stable@mailman.nyi.freebsd.org>;
Sat, 24 Aug 2019 22:28:26 +0000 (UTC)
(envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
(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 46GCbF6Bnjz4Dqn
for <freebsd-stable@freebsd.org>; Sat, 24 Aug 2019 22:28:25 +0000 (UTC)
(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7OMSIoe009091
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
Sun, 25 Aug 2019 01:28:21 +0300 (EEST)
(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7OMSIoe009091
Received: (from kostik@localhost)
by tom.home (8.15.2/8.15.2/Submit) id x7OMSHOo009090;
Sun, 25 Aug 2019 01:28:17 +0300 (EEST)
(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
using -f
Date: Sun, 25 Aug 2019 01:28:17 +0300
From: Konstantin Belousov <kostikbel@gmail.com>
To: Trond =?utf-8?Q?Endrest=C3=B8l?= <trond.endrestol@ximalas.info>
Cc: freebsd-stable@freebsd.org
Subject: Re: ntpd doesn't like ASLR on stable/12 post-r350672
Message-ID: <20190824222817.GJ71821@kib.kiev.ua>
References: <alpine.BSF.2.21.99999.352.1908242135380.6386@enterprise.ximalas.info>
<20190824204114.GG71821@kib.kiev.ua>
<alpine.BSF.2.21.99999.352.1908250012580.6386@enterprise.ximalas.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.BSF.2.21.99999.352.1908250012580.6386@enterprise.ximalas.info>
User-Agent: Mutt/1.12.1 (2019-06-15)
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM,
NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home
X-Rspamd-Queue-Id: 46GCbF6Bnjz4Dqn
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org; dkim=none;
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com
(policy=none);
spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor
denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com
X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[];
NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[];
FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[];
FREEMAIL_FROM(0.00)[gmail.com];
NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain];
HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all];
IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[];
NEURAL_HAM_SHORT(-0.98)[-0.979,0]; RCPT_COUNT_TWO(0.00)[2];
IP_SCORE(0.00)[ip: (-2.58), ipnet: 2001:470::/32(-4.44), asn: 6939(-3.06),
country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[];
R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+];
ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com];
DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>;
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Aug 2019 22:28:26 -0000
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 ?
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.99999.352.1908250012580.6386>