TCP can be subject to Sack Attacks lets fix this issue.
There is a type of attack that a TCP peer can launch on a connection. This is for sure in Rack or BBR and probably even the default stack if it uses lists in sack processing. The idea of the attack is that the attacker is driving you to look at 100's of sack blocks that only update 1 byte. So for example if you have 1 - 10,000 bytes outstanding the attacker sends in something like:
ACK 0 SACK(1-512) SACK(1024 - 1536), SACK(2048-2536), SACK(4096 - 4608), SACK(8192-8704)
This first sack looks fine but then the attacker sends
ACK 0 SACK(1-512) SACK(1025 - 1537), SACK(2049-2537), SACK(4097 - 4609), SACK(8193-8705)
ACK 0 SACK(1-512) SACK(1027 - 1539), SACK(2051-2539), SACK(4099 - 4611), SACK(8195-8707)
...
These blocks are making you hunt across your linked list and split things up so that you have an entry for every other byte. Has your list grows you spend more and more CPU running through the lists. The idea here is the attacker chooses entries as far apart as possible that make you run through the list. This example is small but in theory if the window is open to say 1Meg you could end up with 100's of thousands link list entries.
To combat this we introduce three things.
when the peer requests a very small MSS we stop processing SACK's from them. This prevents a malicious peer from just using a small MSS to do the same thing.
Any time we get a sack block, we use the sack-filter to remove sacks that are smaller than the smallest v4 mss (minus 40 for max TCP options) unless it ties up to snd_max (since that is legal). All other sacks in theory should be at least an MSS. If we get such an attacker that means we basically start skipping all but MSS sized Sacked blocks.
The sack filter used to throw away data when its bounds were exceeded, instead now we increase its size to 15 and then throw away sack's if the filter gets over-run to prevent the malicious attacker from over-running the sack filter and thus we start to process things anyway.
The default stack will need to start using the sack-filter which we have talked about in past conference calls to take full advantage of the protections offered by it (and reduce cpu consumption when processing sacks).
[4 lines not shown]
release: Use qemu when cross-building vm images
For a bit over 5 years, we have used qemu when cross-building cloudware
images; in particular, it's necessary when installing packages which
might include post-install scripts.
Use qemu in the vm-images target too; while "generic" vm images don't
install packages, they still run newaliases and /etc/rc.d/ldconfig,
both of which fail without appropriate emulation.
MFC after: 1 week
ota: Merge one true awk 20240422 (a3b68e649d2d)
Apr 22, 2024:
fixed regex engine gototab reallocation issue that was
introduced during the Nov 24 rewrite. Thanks to Arnold Robbins.
Fixed a scan bug in split in the case the separator is a single
character. thanks to Oguz Ismail for spotting the issue.
Mar 10, 2024:
fixed use-after-free bug in fnematch due to adjbuf invalidating
the pointers to buf. thanks to github user caffe3 for spotting
the issue and providing a fix, and to Miguel Pineiro Jr.
for the alternative fix.
MAX_UTF_BYTES in fnematch has been replaced with awk_mb_cur_max.
thanks to Miguel Pineiro Jr.
Sponsored by: Netflix
rc.conf.5: Fix translation from netmask to cdir
These two should have been 30 bit masks, not 32, as the original
netmasks were 255.255.255.252.
Fixes: cb808de400c7
Noticed by: Kelly Hays
nfsd: Fix Link conformance with RFC8881 for delegations
RFC8881 specifies that, when a Link operation occurs on an
NFSv4, that file delegations issued to other clients must
be recalled. Discovered during a recent discussion on nfsv4 at ietf.org.
Although I have not observed a problem caused by not doing
the required delegation recall, it is definitely required
by the RFC, so this patch makes the server do the recall.
Tested during a recent NFSv4 IETF Bakeathon event.
MFC after: 1 week
lib/clang: clean out old llvm/clang Sparc target remnants
The WITH_LLVM_TARGET_ENABLE_SPARC option was removed a long time ago,
but some ifdefs were still laying around, so clean them up.
PR: 276104
MFC after: 3 days
ota: Import One True Awk 20240422 (a3b68e649d2d)
Apr 22, 2024:
fixed regex engine gototab reallocation issue that was
introduced during the Nov 24 rewrite. Thanks to Arnold Robbins.
Fixed a scan bug in split in the case the separator is a single
character. thanks to Oguz Ismail for spotting the issue.
Mar 10, 2024:
fixed use-after-free bug in fnematch due to adjbuf invalidating
the pointers to buf. thanks to github user caffe3 for spotting
the issue and providing a fix, and to Miguel Pineiro Jr.
for the alternative fix.
MAX_UTF_BYTES in fnematch has been replaced with awk_mb_cur_max.
thanks to Miguel Pineiro Jr.
Note: This brings in the matchop-deref.* files that were missing (but in
FreeBSD already) and adds system-stauts.ok2. The latter has been deleted
in FreeBSD since it does not fit ATF well. Care must be taken to remove it
[3 lines not shown]
rc.conf.5: modernise network_interfaces
It's not 1996 anymore, and we use CIDR nowadays. Update the various
ifconfig_ examples to use CIDR notation instead of netmasks, and also
add an example of a basic ifconfig_ entry that most users will be
interested in.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1217
Fixup: Merge llvm-project release/18.x llvmorg-18.1.5-0-g617a15a9eac9
Update version numbers, config headers, etc. Git tricked me into losing
these before pushing.
PR: 276104
Fixes: d67fc74b9249
MFC after: 3 days
aic7xxx: make target mode enable a device hint
Previously it was only possible to enable target mode for these drivers
by rebuilding the kernel with AHC_TMODE_ENABLE or AHD_TMODE_ENABLE and a
bitmask of which units to statically enable for target mode.
There is no space-savings in the driver by not having AHC_TMODE_ENABLE
set, so in addition to the compile time option lets also introduce some
tunables:
hint.ahc.<unit>.tmode_enable=0/1
hint.ahd.<unit>.tmode_enable=0/1
For compatibility the old behavior is retained, but it can be overridden
with tunables
Signed-off-by: HP van Braam <hp at tmm.cx>
Reviewed by: imp, mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/1208
aic7xxx: aicasm correct include file
aicasm just puts the value of the "-i" passed include file in the
generated file with quotes around it. This means that there are manual
edits made to aic7xxx_reg_print.c and aic79xx_reg_print.c
now we check to see if the value passed to '-i' starts with a '<', if it
does don't output the quotes.
Signed-off-by: HP van Braam <hp at tmm.cx>
Reviewed by: imp (minor code simplification)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1209
vmm.4: Add verbiage about need to load module from loader.conf
PR: 277530
MFC after: 1 week
Co-authored-by: Mateusz Piotrowski <0mp at FreeBSD.org>
(cherry picked from commit d0168b32bc67033414e43f07eff2a4e850652c29)
vmm.4: Add verbiage about need to load module from loader.conf
PR: 277530
MFC after: 1 week
Co-authored-by: Mateusz Piotrowski <0mp at FreeBSD.org>
(cherry picked from commit d0168b32bc67033414e43f07eff2a4e850652c29)
style.9: Document the existence of tools/build/checkstyle9.pl
MFC after: 3 days
Sponsored by: Klara, Inc.
(cherry picked from commit 5626f9e790901999def12040a60746b0ceeb9b95)
style.9: Document the existence of tools/build/checkstyle9.pl
MFC after: 3 days
Sponsored by: Klara, Inc.
(cherry picked from commit 5626f9e790901999def12040a60746b0ceeb9b95)
gettimeofday.2: Do mention improbable future removal
As kib@ noted:
> Obviously gettimeofday(2) is not going to be removed
> even in the far future.
Reported by: kib
Fixes: 4395d3ced5cf Document that gettimeofday() is obsolescent
MFC after: 3 days
(cherry picked from commit 6662c2312e956439652ce2d06b42753b6a78fc61)
gettimeofday.2: Do mention improbable future removal
As kib@ noted:
> Obviously gettimeofday(2) is not going to be removed
> even in the far future.
Reported by: kib
Fixes: 4395d3ced5cf Document that gettimeofday() is obsolescent
MFC after: 3 days
(cherry picked from commit 6662c2312e956439652ce2d06b42753b6a78fc61)