ntpd doesn't like ASLR on stable/12 post-r350672
Trond Endrestøl
trond.endrestol at ximalas.info
Mon Aug 26 09:01:05 UTC 2019
On Sun, 25 Aug 2019 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.
Yes, around line 1001 of contrib/ntp/ntpd/ntpd.c:
/* Setup stack size in preparation for locking pages in memory. */
# if defined(HAVE_MLOCKALL)
# ifdef HAVE_SETRLIMIT
ntp_rlimit(RLIMIT_STACK, DFLT_RLIMIT_STACK * 4096, 4096, "4k");
> 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.
--
Trond.
More information about the freebsd-stable
mailing list