Skip to content

Flowbit ordering cyclic/v7#14909

Draft
inashivb wants to merge 3 commits intoOISF:mainfrom
inashivb:flowbit-ordering-cyclic/v7
Draft

Flowbit ordering cyclic/v7#14909
inashivb wants to merge 3 commits intoOISF:mainfrom
inashivb:flowbit-ordering-cyclic/v7

Conversation

@inashivb
Copy link
Member

@inashivb inashivb commented Feb 26, 2026

Previous PR: #13773

Changes since v6:

  • bug fix for incorrect cycle detection in case of valid Read Write cmd ops in two signatures
  • rebased on top of latest main

Known TODOs:

  • all STODOs in code + commit message
  • more tests
    • small cycles
    • big cycles
    • cycles with varying edge weights
    • unnecessary flowbit ops + multiple complex ordering
  • analysis of the impact of unnecessary flowbit operations that were supposed to be banned but will only produce a warning now

Link to tickets:

SV_BRANCH=OISF/suricata-verify#2936

This solution makes use of the petgraph crate to create a directed
stable graph of flowbits and signatures. Following functions are
exposed:

1. Nodes are created for flowbits as well as signatures per signature.
2. A weighted directed edge is added:
   from flowbit to signature iff the flowbit used a READ cmd in that sig
   from signature to flowbit iff the flowbit used a WRITE cmd in that sig
   The weight of the edge is the "on" bit corresponding to the flowbit
   cmd that is being evaluated.
3. The graph is then normalized i.e. the flowbit nodes are removed and a
   clean directed edge is created making a dependency graph among
   the signatures. This is done because flowbits are inconsequential in
   the final required solution. At this point, the weights of the edges
   going in and out of the flowbits are added (bitwise ORed).
4. The graph is checked for cycles. If a cycle is found, all the
   strongly connected components of the graph are retrieved and they are
   checked if the cycle caused in the graph is with edges that have the
   same weight. This only works if the cycle is between two nodes. STODO
   In case the cycle is formed by edges of different weights, the edge
   with higher weight is deleted. STODO is it the best solution? can we
   get to a situation where no other nodes are reachable?
   In a case where there's a legit cycle i.e. same weights on edges, currently,
   the ruleset is restored to the original.
   STODO Such cycles must result in an error as
   such dependencies cannot be satisfied during runtime anyway.
   If the graph did not have any cycles, this means that there is a
   Directed Acyclic Graph at this point and it is safe to move to the
   next step.
5. Finally, a BFS (Breadth First Search) is performed on the graph
   giving the exact order in which signatures should be such that no
   dependee comes before a dependant.

Bug 7771
Bug 7638
before adding them to the Detection Context's signature list. The
de_ctx->sig_list serves as a sorted signature list that is later passed
on to the grouping fns. If no property of higher value changes the order
of the signatures, the order coming from de_ctx->sig_list is final.

Add the appropriate calls to resolve flowbit dependencies before adding
them to the sig_list. This is especially important for flowbits with
complex ordering involved.

Bug 7771
Bug 7638
@codecov
Copy link

codecov bot commented Feb 26, 2026

Codecov Report

❌ Patch coverage is 89.87730% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.93%. Comparing base (569ba3d) to head (21f37e6).

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #14909      +/-   ##
==========================================
- Coverage   81.93%   81.93%   -0.01%     
==========================================
  Files         986      987       +1     
  Lines      271105   271425     +320     
  Branches    31005    31038      +33     
==========================================
+ Hits       222139   222401     +262     
- Misses      46822    46880      +58     
  Partials     2144     2144              
Flag Coverage Δ
fuzzcorpus 61.05% <89.26%> (+0.05%) ⬆️
livemode 18.22% <7.66%> (-0.05%) ⬇️
netns 18.34% <7.05%> (-0.05%) ⬇️
pcap 45.30% <68.09%> (+0.08%) ⬆️
suricata-verify 58.54% <86.80%> (+<0.01%) ⬆️
unittests 58.86% <62.88%> (+0.02%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline = 29906

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline = 29924

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants