Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dataset set postmatch 5576 v9 #11834

Closed

Conversation

catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5576

Describe changes:

  • detect/dataset: delay set operation after signature full match

SV_BRANCH=OISF/suricata-verify#2000

#11719 with rebase after unset operation has been added

So, now Victor, you will ask me for more tests

Right ?

@suricata-qa
Copy link

ERROR:

ERROR: QA failed on build_asan.

Pipeline 22812

The set operation of dataset keyword was done even if signature
did not fully match, which is not the expected behavior.
We want dataset to behave like flowbits for instance.

This patch changes the behavior of the dataset keyword to do a
match and a post match for the set operation.
The postmatch retrieves the data, using the list identifier
associated to the buffer for this signature.

This avoids to store the buffer(s), when we do not have a
dedicated storage (per signature and per tx) that can own
and clean arbitrary buffers over multiple packets, in
the case the transaction spans over multiple packets
with different tx progresses for instance.
If detection runs on one packet, the InspectionBuffer are
cached and fast to get.
The most expensive case if for multi buffers, where we
need to run detection again, to see which occurences
match all payload keywords and should be added in the dataset.

Ticket: OISF#5576
Copy link

codecov bot commented Sep 25, 2024

Codecov Report

Attention: Patch coverage is 88.31169% with 9 lines in your changes missing coverage. Please review.

Project coverage is 82.56%. Comparing base (45eb7e4) to head (3eea1e0).
Report is 50 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11834      +/-   ##
==========================================
- Coverage   82.60%   82.56%   -0.04%     
==========================================
  Files         912      912              
  Lines      249351   249413      +62     
==========================================
- Hits       205965   205918      -47     
- Misses      43386    43495     +109     
Flag Coverage Δ
fuzzcorpus 60.44% <79.22%> (-0.16%) ⬇️
livemode 18.75% <48.05%> (+0.02%) ⬆️
pcap 44.08% <6.49%> (+0.02%) ⬆️
suricata-verify 62.03% <88.31%> (-0.01%) ⬇️
unittests 58.92% <6.49%> (-0.01%) ⬇️

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

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 22853

@victorjulien
Copy link
Member

I would like to avoid rerunning transforms and detection. One alternative way could be to explore having a immediate dataset operation that stores the data in a temporary location (det_ctx for example) and then uses that from post-match.

@catenacyber
Copy link
Contributor Author

I would like to avoid rerunning transforms and detection.

Ok...
Note that transforms should be cached in the regular case ;-)

One alternative way could be to explore having an immediate dataset operation that stores the data in a temporary location (det_ctx for example) and then uses that from post-match.

This is problematic as https://redmine.openinfosecfoundation.org/issues/7197 shows it for flowvar
If the rule match spans over multiple packets (because of different tx progress), we do not have a good location to store it
What do you suggest ?

@catenacyber
Copy link
Contributor Author

Next in #11962

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