Bug 262031 - net/ntp 4.2.8p15_4 starts with error: Cannot set RLIMIT_MEMLOCK
Summary: net/ntp 4.2.8p15_4 starts with error: Cannot set RLIMIT_MEMLOCK
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-18 11:05 UTC by p5B2EA84B3
Modified: 2022-05-09 20:51 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (cy)
koobs: merge-quarterly?


Attachments
Reverse the ASLR crash mitigation. (1.99 KB, patch)
2022-02-18 18:43 UTC, Cy Schubert
no flags Details | Diff
Restore all prior to ASLR mitigations (2.38 KB, patch)
2022-02-18 20:39 UTC, Cy Schubert
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description p5B2EA84B3 2022-02-18 11:05:30 UTC
Having read https://reviews.freebsd.org/D21581
Administrators wishing to preserve the historic behavior can do so by adding 'rlimit memlock 32' to ntp.conf. 

Having done so starting ntpd still issues errors in logfiles
 ntpd[96018]: Cannot set RLIMIT_MEMLOCK: Operation not permitted

As adding rlimit memlock to ntp.conf makes no difference the problem is not solved.
Setting rlimit is not recognized by ntpd.


ntp-4.2.8p15_4:
        FreeBSD_version: 1300139
        build_timestamp: 2022-02-15T03:34:40+0000
        built_by       : poudriere-git-3.3.99.20211130
        cpe            : cpe:2.3:a:ntp:ntp:4.2.8p15:::::freebsd13:x86:4
        port_checkout_unclean: no
        port_git_hash  : a18d5b7f5
        ports_top_checkout_unclean: no
        ports_top_git_hash: 0ecdbd461
        repo_type      : binary
        repository     : local
Comment 1 Marek Zarychta 2022-02-18 11:08:12 UTC
Maybe loading mac_ntpd.ko will help ?
Comment 2 p5B2EA84B3 2022-02-18 16:04:30 UTC
 # dmesg -a | grep ntp
Security policy loaded: MAC/ntpd (mac_ntpd)
Feb 18 16:58:38  ntpd[16778]: Cannot set RLIMIT_MEMLOCK: Operation not permitted
Comment 3 Cy Schubert freebsd_committer freebsd_triage 2022-02-18 16:46:17 UTC
Reset importance. This is an uncommon issue.
Comment 4 Cy Schubert freebsd_committer freebsd_triage 2022-02-18 16:47:34 UTC
I have a series of questions. So that none remain unanswered, starting with the first question only:

What does uname -a say?
Comment 5 p5B2EA84B3 2022-02-18 17:44:31 UTC
 # uname -mrsv
FreeBSD 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n249403-c437ff145cb: Thu Feb 10 02:45:52 UTC 2022     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC  i38
Comment 6 Cy Schubert freebsd_committer freebsd_triage 2022-02-18 18:01:27 UTC
This says that,

#define __FreeBSD_version 1300525

It also appears that 40d6b2a3624ca91ab6ee084d4f99bf2694276b7b has been applied to -stable/13 as well.

Can you please provide output from:

sysctl -a | grep aslr
Comment 7 p5B2EA84B3 2022-02-18 18:22:32 UTC
 # sysctl -a | grep aslr
kern.elf32.aslr.stack_gap: 3
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
vm.aslr_restarts: 40688
Comment 8 Cy Schubert freebsd_committer freebsd_triage 2022-02-18 18:43:05 UTC
Created attachment 231924 [details]
Reverse the ASLR crash mitigation.

This patch will reverse the ntpd ASLR crash mitigation. However, there is no fix for if ntpd crashes when ASLR is enabled and the only recourse is to use procctl(1) to implement the reversal in its rc.d script.

IIRC the recent fix to ASLR/PIE regressions may have been MFCed to stable/13 for amd64 only. Please try the patch. If it works we can apply the patch to the port. If it doesn't then I'm sorry but we are caught between a rock and a hard place -- either way there are consequences.
Comment 9 p5B2EA84B3 2022-02-18 19:24:38 UTC
Having applied patches and installed:

Installed packages to be UPGRADED:
        ntp: 4.2.8p15_4 -> 4.2.8p15_5 [local]

Number of packages to be upgraded: 1

2 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching ntp-4.2.8p15_5.pkg: 100%    2 MiB   1.7MB/s    00:01    
Checking integrity... done (0 conflicting)
[1/1] Upgrading ntp from 4.2.8p15_4 to 4.2.8p15_5...
[1/1] Extracting ntp-4.2.8p15_5: 100%

Fr. 18.02.2022 20:12:15 CET
 # sysctl vm.aslr_restarts
vm.aslr_restarts: 48789

Fr. 18.02.2022 20:12:35 CET
# service ntpd stop
Stopping ntpd.

Fr. 18.02.2022 20:12:47 CET
# sysctl vm.aslr_restarts
vm.aslr_restarts: 48789

Fr. 18.02.2022 20:13:45 CET
# service ntpd start
Starting ntpd.

Fr. 18.02.2022 20:14:30 CET
# sysctl vm.aslr_restarts
vm.aslr_restarts: 48792

Fr. 18.02.2022 20:15:30 CET
# sysctl vm.aslr_restarts
vm.aslr_restarts: 49102

Feb 18 20:14:30  ntpd[5201]: Cannot set RLIMIT_MEMLOCK: Operation not permitted
Comment 10 Cy Schubert freebsd_committer freebsd_triage 2022-02-18 20:39:42 UTC
Created attachment 231931 [details]
Restore all prior to ASLR mitigations

There was another ASLR mitigation applied. This patch removes it as well.
Comment 11 commit-hook freebsd_committer freebsd_triage 2022-02-18 21:03:05 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=c2a26c7a01c70722c50c0958fa2860633ced64c9

commit c2a26c7a01c70722c50c0958fa2860633ced64c9
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-02-18 20:45:07 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-02-18 21:01:48 +0000

    net/ntp: Restore previous behaviour

    Restore ntp to prior to the ASLR mitigations applied.

    When ASLR and subsequently PIE were committed to the FreeBSD kernel, ntpd
    would segfault due to insufficient stack. This was because stack gap was
    not taken into account by applications requesting stack and/or memory
    limits. (BTW, this problem also affected firefox and thunderbird.)

    This subsequently caused disabling of rlimit memlock, which could not be
    avoided under the previous implementation of ASLR:

            Cannot set RLIMIT_MEMLOCK: Operation not permitted

    Since then a number of improvments to ASLR stack gap implementation have
    rendered the mitigations unnecessary. The mitigations initially developed
    here at FreeBSD were subsequently upstreamed (noticed by the folks at
    nwtime.org and automatically upstreamed). The mitigations have been
    reversed in the base system. This patch reverses the ASLR mitigations in
    the port as well.

    PR:             262031
    Reported by:    p5B2E9A8F@t-online.de

 net/ntp/Makefile                |  2 +-
 net/ntp/files/patch-ntpd_ntpd.c | 54 +++++++++++++++++++++++++++++------------
 2 files changed, 40 insertions(+), 16 deletions(-)
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2022-02-22 23:24:34 UTC
^Triage: Are quarterly users also affected Cy?
Comment 13 Cy Schubert freebsd_committer freebsd_triage 2022-02-23 00:09:09 UTC
(In reply to Kubilay Kocak from comment #12)
I think we should wait and see if this causes other fallout. Let's wait before MFH.
Comment 14 Cy Schubert freebsd_committer freebsd_triage 2022-02-23 00:17:23 UTC
Sent an email to our upstream.
Comment 15 Cy Schubert freebsd_committer freebsd_triage 2022-05-09 20:51:09 UTC
The mitigations still exist in quarterly. They are redundant.