NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38. See LockingNtpdInMemoryDev for discussion of this topic.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
6.9. Locking ntpd in memory
Related Topics: NtpdProcessResidencyIssues
, Bug #387
will lock itself in memory if the appropriate system calls are available.
This is generally good because it means
can quickly respond to time updates.
ntp-4.2.6 and earlier
For some OSes, the amount of locked memory is currently hardcoded in
This is Suboptimal.
- AIX: reserve 32k of extra stack space (less 8 4k pages).
- WINNT callls
VirtualLock(), at about 4MB(?).
- Systems that use
mlockall() seem to reserve an extra 50 4k pages.
- this seems to be too much for some *BSD systems, and not enough for some linux systems.
rlimit memlock 0
then while memory will be locked, there will be no limit to how much memory is locked. This behavior is OS-specific. Some will only lock what is needed, some will lock current memory. Sometimes more memory is needed and this may or may not be allowed. But this needs to be re-examined and better documented, as there is code in
and then later, when
is called, we get a value for
rlimit memlock -1
does not call
rlimit memlock 0
then the previous behavior is done -
is called but