icmp6: bring rate limiting on a par with IPv4
Use counter_ratecheck() instead of racy and slow ppsratecheck. Use a
separate counter for every currently known type of ICMPv6. Provide logging
of ratelimit events. Provide jitter to counter open UDP port detection.
Reviewed by: tuexen, zlei
Differential Revision: https://reviews.freebsd.org/D44482
(cherry picked from commit a03aff88a14448c3084a0384082ec996d7213897)
icmp6: move ICMPv6 related tunables to the files where they are used
Most of them can be declared as static after the move out of in6_proto.c.
Keeping sysctl(9) declarations with their text descriptions next to the
variable declaration create self-documenting code. There should be no
functional changes.
Differential Revision: https://reviews.freebsd.org/D44481
(cherry picked from commit 4f96be33fe7676c69c5abb476bb09bba0c63a3f4)
icmp: improve ICMP limit jitter
Instead of fixing up invalid values set by a user in badport_bandlim()
which is a fast path function, provide a sysctl handler
sysctl_icmplim_and_jitter(), that will check that jitter is less than the
limit.
Provide jitter initilization function icmplim_new_jitter() used at boot,
in the sysctl handler and when we actually hit the limit. This also fixes
no jitter on a fresh booted system until first limit hit.
Instead of CVE number provide link the the actual paper that explains what
and why we are doing here. The CVE number isn't very informative, it will
just tell you what RedHat version you need to upgrade to.
Reviewed by: kp, tuexen, zlei
Differential Revision: https://reviews.freebsd.org/D44478
(cherry picked from commit ac44739fd834f51cacb26485a4140fd482e20150)
icmp: when logging ICMP ratelimiting message use correct jitter value
The limiting of the very last second has been done using certain jitter
value. We update the jitter for the next second. But the logging should
report the jitter before the change.
Reviewed by: kp, tuexen, zlei
Differential Revision: https://reviews.freebsd.org/D44477
(cherry picked from commit b508545ce044dbfdd83da772e73f969a3713d59d)
icmp: do not store per-VNET identical array of strings
We need per-VNET struct counter_rate, but we don't need per-VNET set of
const char *. Also, identical word "response" can go into the format
string instead of being stored 7 times.
Reviewed by: kp, zlei, tuexen
Differential Revision: https://reviews.freebsd.org/D44475
(cherry picked from commit 7142ab4790666022a2a3d85910e9cd8e241d9b87)
test: disable sys.kern.unix_seqpacket_test.random_eor_and_waitall
It's been failing for a while, at least some of the time.
PR: 279994
Sponsored by: Netflix
release: Publish non-uploaded cloudware bits
[MFC note: We don't have BASIC-CLOUDINIT or support for multiple disk
formats or filesystems in VMs on 13.x so this MFC only does BASIC-CI
and only for UFS on RAW.]
While most "cloudware" (AWS, Azure, GCP, Vagrant) images get uploaded
to their respective clouds, we have two images -- BASIC-CI and
BASIC-CLOUDINIT -- which are published via the FTP mirrors. We have
been handling these using a manual and error-prone process of copying
them from the internal build directories into the FTP staging tree,
but they should be handled using the "make install ftp-stage"
mechanism which is used for all the other published images.
This commit 1. Adds a new 'make cloud-install' target which is run as
part of 'make install' and installs BASIC-CI and BASIC-CLOUDINIT images,
and 2. Extends 'make ftp-stage' in Makefile.mirrors to copy those bits
into the FTP staging area.
[7 lines not shown]
release: Publish non-uploaded cloudware bits
While most "cloudware" (AWS, Azure, GCP, Vagrant) images get uploaded
to their respective clouds, we have two images -- BASIC-CI and
BASIC-CLOUDINIT -- which are published via the FTP mirrors. We have
been handling these using a manual and error-prone process of copying
them from the internal build directories into the FTP staging tree,
but they should be handled using the "make install ftp-stage"
mechanism which is used for all the other published images.
This commit 1. Adds a new 'make cloud-install' target which is run as
part of 'make install' and installs BASIC-CI and BASIC-CLOUDINIT images,
and 2. Extends 'make ftp-stage' in Makefile.mirrors to copy those bits
into the FTP staging area.
As a side benefit, this will also make BASIC-CI and BASIC-CLOUDINIT
images available for arm64; until now they have only been available
for amd64.
[3 lines not shown]
release: Don't publish CW if !WITH_CLOUDWARE
If WITH_CLOUDWARE is not set, we didn't build BASIC-CLOUDWARE; don't try
to install it into the /VM-IMAGES/ directory as part of ftp-stage.
Fixes: 4771c2e9d1c7 "release: Publish non-uploaded cloudware bits"
MFC after: 6 days
(cherry picked from commit 836f00ebb96ac343e0f8a68ea264d2d330198488)
stand: module: unlink the entire tail when dependencies fail to load
Assume you have loader configured to load linux64, which has a
dependency on both linux_common and mqueuefs but neither the kernel
nor kernel config in question have the mqueuefs module included.
When the load command for linux64 fails to find mqueuefs, it will
free both linux64 and linux_common as they were loaded first, but only
linux64 gets removed from the module list. As a result, future
traversals hit an easy use-after-free with linux_common.
Fix it so that we unlink the entire tail of the list. Anything after
the initially loaded module is, by definition, a dependency on the
loaded module while we're still in the load command, so we can just
discard the entire tail. If linux_common were loaded before linux64, it
should not move to a position during this load where it would suddenly
be missing from the view presented to the kernel.
Reported by: philip
[3 lines not shown]
ctladm: Fix a race when loading ctl.ko
If multiple ctladm processes try to load ctl.ko at the same time, only
one will succeed. Handle this possibility by retrying the operation
(open /dev/cam/ctl) if kldload returns EEXIST, rather than bailing.
This at least helps ensure that ctladm tests can be run in parallel
when ctl.ko is not preloaded.
Reviewed by: asomers
MFC after: 1 week
ext4_ext_tree_init: correct memset initialization
gcc -Wmemset-elt-size diagnosed this. The code was only initializing
1/4 of the array. However, it was actually harmless, as the only caller
had done an M_ZERO allocation anyway.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D45701
cdefs.h: add __inline to __always_inline
Add __inline to the __always_inline macro to quiet dozens of gcc
warnings of the form:
warning: 'always_inline' function might not be inlinable [-Wattributes]
It's clearly the intention of the __always_inline macro applied to a
function to inline the function. However, gcc seems to be picky with
the -Wattributes. It appears that __attribute__((__always_inline__))
was intended to apply to inline functions, as in, function declarations
with the attribute should also be declared as inline. Both clang and
gcc sources themselves use the two in combination:
inline __attribute__((__always_inline__))
FreeBSD sources mostly only use __always_inline, without the inline
keyword. Only a few files in libmsun used both.
Reviewed by: imp, kib, olce
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45711
isp: fix ISPCTL_ABORT_CMD switch case
Prevent kernel panic by not running ISPCTL_FCLINK_TEST after a
failed ISPCTL_ABORT_CMD.
Reviewed by: mav
Tested by: Arne Steinkamm <arne at steinkamm.com>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45718
netlink/route: provide pre-2.6.19 Linux compat shim
The old Linux used 8-bit rtm_table field of the RTM_NEWROUTE message to
specify routing table id. Modern netlink uses RTA_TABLE 32-bit attribute.
Unfortunately, there is modern software (namely bird) that would prefer
the old API as long as the routing table id fits into 8-bit.
PR: 279662
(cherry picked from commit f34aca55adef1e28cd68b2e6705a0cac03f0238e)
arm64/vmm: Fix the SPAN check
When raising an exception we may need to set the SPSR_EL1.PAN field.
The check for this was incorrect meaning it would be set when it
shouldn't be.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45717
hwpmc/arm64: Support the kernel booting to VHE
When booting to VHE we need to handle using the PMU at either EL1 or
EL2. WE already support EL1 so add support for EL2.
Reviewed by: mhorne
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45527
arm: Start to remove the now unneeded acle-compat.h
All supported compilers provide the acle macros so we don't need the
backup versions.
Sponsored by: Arm Ltd