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

Applayer plugin 5053 v3.16 #12256

Closed
wants to merge 15 commits into from

Conversation

catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5053
https://redmine.openinfosecfoundation.org/issues/7437

Describe changes:

  • get ready to use dynamic number of app-layer protos (also work with static constant) in all places
  • preventive fix of macro with parenthesis cc @jufajardini
  • app-layer plugins
  • remove limitation on probing parsers about 32 protocols

This PR contains #12233 + #12234 and more

#12163 rebased after latest merge of #12232

instead of a global variable.

For easier initialization with dynamic number of protocols
for expectation_proto

Ticket: 5053
so that we can use safely EXCEPTION_POLICY_MAX*sizeof(x)
Ticket: 5053

delay after initialization so that StringToAppProto works
Because some alprotos will remain static and defined as a constant,
such as ALPROTO_UNKNOWN=0, or ALPROTO_FAILED.

The regular already used protocols keep for now their static
identifier such as ALPROTO_SNMP, but this could be made more
dynamic in a later commit.

ALPROTO_FAILED was used in comparison and these needed to change to use
either ALPROTO_MAX or use standard function AppProtoIsValid
Ticket: 5053

The names are now dynamically registered at runtime.
The AppProto alproto enum identifiers are still static for now.

This is the final step before app-layer plugins.
There was an implicit limit of 32 app-layer protocols
used by probing parsers through a mask, meaning that
Suricata should not support more than 32 app-layer protocols
in total.

This limit is relaxed to each flow not being able to
run more than 32 probing parsers, meaning that for each source
and destination port combination, the sum of registered
probing parsers should not exceed 32, even if there are more
than 32 in total.

Ticket: 7437
@victorjulien
Copy link
Member

Added skip qa to avoid qalab backlog this week.

Copy link

codecov bot commented Dec 10, 2024

Codecov Report

Attention: Patch coverage is 78.61272% with 111 lines in your changes missing coverage. Please review.

Project coverage is 80.64%. Comparing base (38d7900) to head (a21b697).
Report is 23 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12256      +/-   ##
==========================================
- Coverage   83.21%   80.64%   -2.58%     
==========================================
  Files         912      914       +2     
  Lines      257183   257599     +416     
==========================================
- Hits       214025   207739    -6286     
- Misses      43158    49860    +6702     
Flag Coverage Δ
fuzzcorpus 56.63% <67.35%> (-4.44%) ⬇️
livemode 19.38% <49.77%> (-0.05%) ⬇️
pcap 44.45% <67.12%> (+0.05%) ⬆️
suricata-verify 62.81% <73.05%> (+0.01%) ⬆️
unittests 58.49% <61.84%> (-0.70%) ⬇️

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

@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPW1_stats_chk
.app_layer.error.tls.parser 1152 1203 104.43%
SURI_TLPR1_stats_chk
.app_layer.tx.ftp 95972 102934 107.25%
.ftp.memuse 3102 10661 343.68%

Pipeline 23922

@catenacyber
Copy link
Contributor Author

As QA shows, we should get first subpart of this PR #12307

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