Parallel builds caused issues during `cargo vendor`. So do just a single
thread build.
make[4]: Entering directory '/__w/suricata/suricata/rust'
cbindgen --config /__w/suricata/suricata/rust/cbindgen.toml \
--quiet --output /__w/suricata/suricata/rust/dist/rust-bindings.h
CARGO_HOME="/github/home/.cargo" /usr/bin/cargo vendor
Blocking waiting for file lock on package cache
Blocking waiting for file lock on package cache
ERROR: Couldn't execute `cargo metadata` with manifest "/__w/suricata/suricata/rust/Cargo.toml": Metadata(Output { status: ExitStatus(unix_wait_status(25856)), stdout: "", stderr: " Blocking waiting for file lock on package cache\n Blocking waiting for file lock on package cache\nerror: failed to download `adler v1.0.2`\n\nCaused by:\n unable to get packages from source\n\nCaused by:\n failed to parse manifest at `/github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/adler-1.0.2/Cargo.toml`\n\nCaused by:\n no targets specified in the manifest\n either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present\n" })
ERROR: Couldn't generate bindings for /__w/suricata/suricata/rust.
make[4]: *** [Makefile:597: dist/rust-bindings.h] Error 1
make[4]: *** Waiting for unfinished jobs....
Victor Julien [Mon, 25 Sep 2023 08:16:27 +0000 (10:16 +0200)]
detect/isdataat: optimize recursion mismatches
Since recursive content matching goes through the buffer from left to
right, it is possible to bail early when isdataat is part of the
recursive checking. If `isdataat:50,relative` fails for offset 10, it
will surely also fail for offset 20. So break inspection in such cases.
The exception is for dynamic isdataat, where the value is determined
by a prior byte_extract that may be updated during the recursion.
Use stack local var instead of DetectEngineThreadCtx member. Instead
setup a stack local struct that both counts and holds the limit. Make sure
the limit is a const so we can avoid rereading it.
This is part of an effort to reduce the size of the DetectEngineThreadCtx
structure and reduce the number of memory writes to it. Additionally, it
is part of an effect to reduce the number of places where detection
tracks various forms of state.
Vincent Li [Wed, 2 Aug 2023 20:31:54 +0000 (20:31 +0000)]
ebpf: Update eBPF map to BTF defined map
legacy map definition is removed from libbpf1.0+.
update the legacy map definition to BTF defined map.
Distros with < libbpf1.0 (0.5, 0.6, 0.7, 0.8) bpf_helpers.h
support BTF map definition, this change does not break
old libbpf and support new libpbf1.0+.
Bug: #6250
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com> Co-authored-by: Victor Julien <vjulien@oisf.net>
With the changes in the probing_ts function, this other one could become
obsolete. Remove it, and directly call `parser::parse_request` when
checking for gaps, instead.
Some non-pgsql traffic seen by Suricata is mistankenly identified as
pgsql, as the probing function is too generic. Now, if the parser sees
an unknown message type, even if it looks like pgsql, it will fail.
We had unkonwn message type for the backend, but not the frontend
messages. It's important to better identify those to improve pgsql
probing functions.
Shivani Bhardwaj [Thu, 16 Nov 2023 08:18:06 +0000 (13:48 +0530)]
detect/engine: fix whitelisted port range check
So far, the condition for checking if the whitelisted port was in the
port range of "a" said
a->port >= w->port && a->port2 <= w->port
But, if a->port <= a->port2, this condition could only be true when
a->port == w->port == a->port2. However, the motivation for this fn was
to be able to find if the whitelisted port for a carrier proto already
was in the range of the given protocol and calculate a score for the
port accordingly.
Fix the range check such that a->port <= w->port <= a->port2.
Shivani Bhardwaj [Thu, 16 Nov 2023 08:11:39 +0000 (13:41 +0530)]
detect: rename whitelist to score
The term "whitelist" is actually used to store a list of DetectPort type
items for tcp and udp in detect.h. Using the same term for also keeping
the score that affects the grouping of rules is confusing. So, rename
the variable to "score".
DetectFlagsSignatureNeedsSynPackets checks if TCP SYN flag is set among
other flags.
DetectFlagsSignatureNeedsSynOnlyPackets checks if only TCP SYN flag is
set and no other flag.
Since DetectFlagsSignatureNeedsSynOnlyPackets also already checks for
TCP SYN flag, it does not need to be used in combination with
DetectFlagsSignatureNeedsSynPackets as this fn seems to be the superset
of the former.
Victor Julien [Mon, 25 Sep 2023 09:58:03 +0000 (11:58 +0200)]
flow/timeout: use single packet for timeout handling
In the FlowFinish logic, one or two pseudo packets are used to finish flow
handling. In the case of 2 (one per direction), the logic first set up the
2 packets, then it would process them one by one. This lead to poor cache
locality.
This patch processes the first packet entirely first, followed by the second
packet.
Victor Julien [Fri, 22 Sep 2023 19:08:29 +0000 (21:08 +0200)]
detect: reimplement discontinue matching logic
Previously various steps in the content inspection logic would use
a variable in the DetectEngineThreadCtx to flag that matching should
be discontinued.
This patch reimplements this logic by using a new return code instead.
Split content inspection into public and private version, so that
common initialization can be done in a single place.
Victor Julien [Wed, 22 Nov 2023 08:03:09 +0000 (09:03 +0100)]
flow: fix condition signalling
Signal threads while holding lock. This should make the signalling
more reliable.
From PTHREAD_COND(3):
"Unlocking the mutex and suspending on the condition variable is done
atomically. Thus, if all threads always acquire the mutex before
signaling the condition, this guarantees that the condition cannot be
signaled (and thus ignored) between the time a thread locks the
mutex and the time it waits on the condition variable."
Victor Julien [Wed, 13 Sep 2023 05:01:53 +0000 (07:01 +0200)]
packetpool: dynamic return threshold
Problem:
In pcap autofp mode, there is one threads reading packets (RX). These packets
are then passed on to worker threads. When these workers are done with a
packet, they return packets to the pcap reader threads packet pool, which is
the owner of the packets. Since this requires expensive synchronization between
threads, there is logic in place to batch this operation.
When the reader thread depletes its pool, it notifies the other threads that
it is starving and that a sync needs to happen asap. Then the reader enters
a wait state. During this time no new packets are read.
However, there is a problem with this approach. When the reader encountered
an empty pool, it would set an atomic flag that it needed a sync. The first
worker to return a packet to the pool would then set this flag, sync, and
unset the flag. This forced sync could result in just a single packet being
synchronized, or several. So if unlucky, the reader would just get a single
packet before hitting the same condition again.
Solution:
This patch updates the logic to use a new approach. Instead of using a
binary flag approach where the behavior only changes when the reader is
already starved, it uses a dynamic sync threshold that is controlled by
the reader. The reader keeps a running count of packets it its pool,
and calculates the percentage of available packets. This percentage is
then used to set the sync threshold.
When the pool is starved, it sets the threshold to 1 (sync for each packet).
After each successful get/sync the threshold is adjusted.
And failures should be handled to say that the rule failed to load
Reverts the fix by 299ee6ed5561f01575150b436d5db31485dab146
that was simple, but not complete (memory leak),
to have this bigger API change which simplifies code.