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

Dynamic alprotos : make SNMP totally dynamic v3 #12408

Closed

Conversation

catenacyber
Copy link
Contributor

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

Describe changes:

  • snmp: register protocol dynamically, to do so :
    • make some arrays even more dynamic
    • add an helper function AppProtoNewProtoFromString
    • have plugins be able to log flow or packet direction
  • detect: fix overflow for files protocol as reported by coverity

#12406 with clean history and removed the rust cleanups
@jasonish what do you think about commit aa32e81 ?

Already quite a few things going on here, so stopping here before adding the example of a template plugin

CID 1640392

Would happen only if we reached 15 protocols handling files
Ticket: 5053

Do not asume that we know the number of alprotos at the end
of AppLayerNamesSetup, but make arrays allocated by later
AppLayerProtoDetectSetup dynamic so that it can be reallocated
from AppLayerParserRegisterProtocolParsers

This helps have a single entry point for a protocol like SNMP
So that we do not have to know g_alproto_max to register
dynamically a new protocol from its name
and cast

and also remove unneeded mut

and rustfmt
@catenacyber
Copy link
Contributor Author

The rust cleanup has its own PR #12409

Copy link

codecov bot commented Jan 16, 2025

Codecov Report

Attention: Patch coverage is 80.95238% with 12 lines in your changes missing coverage. Please review.

Project coverage is 80.79%. Comparing base (078c646) to head (4413a2d).
Report is 12 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12408      +/-   ##
==========================================
+ Coverage   80.63%   80.79%   +0.15%     
==========================================
  Files         917      917              
  Lines      258687   258725      +38     
==========================================
+ Hits       208601   209028     +427     
+ Misses      50086    49697     -389     
Flag Coverage Δ
fuzzcorpus 57.23% <77.41%> (+0.41%) ⬆️
livemode 19.43% <70.96%> (+0.03%) ⬆️
pcap 44.34% <80.64%> (+0.07%) ⬆️
suricata-verify 63.29% <82.25%> (+0.06%) ⬆️
unittests 58.53% <70.96%> (+0.01%) ⬆️

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

@@ -159,8 +159,7 @@ int SCPluginRegisterAppLayer(SCAppLayerPlugin *plugin)
if (plugin->version != SC_PLUGIN_API_VERSION) {
return 1;
}
AppProto alproto = g_alproto_max;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So with this method not just for plugins now, where would a sensible place be to move it, and rename to something more like SCRegisterAppLayer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SCPluginRegisterAppLayer is still just for plugins.

Or did you talk about another thing with this method ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm... thought it may have been used by snmp.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plugins call SCPluginRegisterAppLayer which registers the name, pre-register the parser, the logger and the detection, using the logic that was there

Dynamic SNMP only uses the parser registration where it now starts by registering the name, pre-registering the logger and the detection, and does the parser registration as usual

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 24240

@catenacyber
Copy link
Contributor Author

Next in #12414

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