git: af949c590bd8 - main - Disable stack gap for ntpd during build.

[Shawn Webb]

On Fri, May 21, 2021 at 03:15:43PM +0100, Jessica Clarke wrote:
> > On 21 May 2021, at 15:11, Marcin Wojtas <mw at semihalf.com> wrote:
> > 
> > Hi Jess
> > 
> > pt., 21 maj 2021 o 15:39 Jessica Clarke <jrtc27 at freebsd.org> napisał(a):
> >> 
> >> On 21 May 2021, at 14:34, Marcin Wojtas <mw at FreeBSD.org> wrote:
> >>> 
> >>> The branch main has been updated by mw:
> >>> 
> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=af949c590bd8a00a5973b5875d7e0fa6832ea64a
> >>> 
> >>> commit af949c590bd8a00a5973b5875d7e0fa6832ea64a
> >>> Author:     Marcin Wojtas <mw at FreeBSD.org>
> >>> AuthorDate: 2021-05-21 09:29:22 +0000
> >>> Commit:     Marcin Wojtas <mw at FreeBSD.org>
> >>> CommitDate: 2021-05-21 13:33:06 +0000
> >>> 
> >>>   Disable stack gap for ntpd during build.
> >>> 
> >>>   When starting, ntpd calls setrlimit(2) to limit maximum size of its
> >>>   stack. The stack limit chosen by ntpd is 200K, so when stack gap
> >>>   is enabled, the stack gap is larger than this limit, which results
> >>>   in ntpd crashing.
> >> 
> >> Isn’t the bug that the unusable gap counts as usage?
> >> 
> >> Jess
> >> 
> > 
> > An alternative solution was submitted
> > (https://reviews.freebsd.org/D29832), so that to extend the limit for
> > ntpd, but eventually it was recommended to simple disable the stack
> > gap for it until it's fixed upstream (see the last comment in the
> > linked revision).
> 
> That’s my point, there is nothing to “fix” upstream. NTPD uses less than 200K
> of stack, thus it is perfectly reasonable for it to set its limit to that. The
> fact that FreeBSD decides to count an arbitrary, non-deterministic amount of
> additional unusable virtual address space towards that limit is not its fault,
> but a bug in FreeBSD that needs to be fixed as it’s entirely unreasonable for
> applications to have to account for that.

Also: Disabling randomization of any part of the address space makes
randomization other parts of the address space moot. Toggling ASLR
should be all-or-nothing. Especially true for randomizing the stack.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/dev-commits-src-main/attachments/20210521/c66c4aee/attachment.sig>