Conversation
instead of a global variable. For easier initialization with dynamic number of protocols
for expectation_proto Ticket: 5053
for alproto_names Ticket: 5053
Ticket: 5053
so that we can use safely EXCEPTION_POLICY_MAX*sizeof(x)
Ticket: 5053 delay after initialization so that StringToAppProto works
Ticket: 5053
As too many cases are found when splitting tcp payload
As it is also used for HTTP/1
Ticket: 5053 The names are nwo dynamic
Ticket: 5053
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12066 +/- ##
==========================================
- Coverage 83.42% 83.29% -0.14%
==========================================
Files 910 910
Lines 257642 257757 +115
==========================================
- Hits 214949 214698 -251
- Misses 42693 43059 +366
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: QA ran without warnings. Pipeline 23220 |
victorjulien
left a comment
There was a problem hiding this comment.
Code looks mostly ok, have some style issues and minor other things inline.
Does need a lot more documentation in the commit messages, as well as more comments in the new functions, structs and global variables.
| #include "app-layer-protos.h" | ||
| #include "rust.h" | ||
|
|
||
| AppProto ALPROTO_FAILED = ALPROTO_MAX_STATIC; |
There was a problem hiding this comment.
I don't like the coding style violations here, macro style name for vars, function style name for a var, etc.
There was a problem hiding this comment.
can also imagine that the now global var ALPROTO_MAX would be replaced by a function AppProtoMax() or something.
There was a problem hiding this comment.
Why a function instead of a variable ?
| return ALPROTO_UNKNOWN; | ||
| } | ||
|
|
||
| void RegisterAppProtoString(AppProto alproto, const char *proto_name) |
There was a problem hiding this comment.
can ALPROTO_FAILED just be a constant instead of having it be a dynamic value for no real reason I can see?
There was a problem hiding this comment.
ALPROTO_FAILED is used in comparison like < ALPROTO_FAILED ...
Will think about it again
There was a problem hiding this comment.
Looks like we can move ALPROTO_FAILED to 1 and change the comparisons... in next PR version
| /***** Setup/General Registration *****/ | ||
| static void AppLayerNamesSetup(void) | ||
| { | ||
| RegisterAppProtoString(ALPROTO_UNKNOWN, "unknown"); |
There was a problem hiding this comment.
should this move into the actual parser implementations?
There was a problem hiding this comment.
Maybe as a next step that makes a protocol like SNMP behave like a plugin ? (no static definition of ALPROTO_SNMP)
|
|
||
| int SCPluginRegisterCapture(SCCapturePlugin *); | ||
|
|
||
| typedef struct SCAppLayerPlugin_ { |
There was a problem hiding this comment.
@catenacyber Do you see this as being only used for app-layer plugins? Or become the new way to register app-layers? If the latter, it should be more generic than plugin context. Also its a lot odd to be here, but then used in detect-engine-register.c, I think it should be localized to plugin specific code.
There was a problem hiding this comment.
Just for some context, if "plugin" is mentioned outside of a file with plugin in the name, its probably suspect to a leaky abstraction. We have this for capture plugins still, but have got rid of it for other types of plugins.
There was a problem hiding this comment.
Do you see this as being only used for app-layer plugins?
That is what I thought at first
There was a problem hiding this comment.
Ok, then I'd move the usage of the Plugin struct out of the app-layer. Keep it within the plugin API, and not the app-layer API. Then register it from there so the plugin interface doesn't leak into the app-layer API if that makes sense.
There was a problem hiding this comment.
What do you mean ? For example, Which line of code should I move from which file to which file ?
There was a problem hiding this comment.
I guess this:
#ifdef HAVE_PLUGINS
for (size_t i = 0; i < app_layer_plugins_nb; i++) {
SCAppLayerPlugin *app_layer_plugin = SCPluginFindAppLayerByIndex(i);
if (app_layer_plugin == NULL) {
break;
}
app_layer_plugin->Register();
}
#endif
it doesn't really need HAVE_PLUGINS, its simply dynamic app-layer registration right?
It just feels weird that the app-layer "layer" is plugin aware, instead the plugin-layer would be app-layer aware.
Can we get a sample plugin for CI purposes to make sure it works? Might help reason about it.
There was a problem hiding this comment.
Can we get a sample plugin for CI purposes to make sure it works?
Example plugin at https://github.com/catenacyber/suricata-zabbix ;-)
It just feels weird that the app-layer "layer" is plugin aware, instead the plugin-layer would be app-layer aware.
I see what you mean.
The problem is different initialization timings :
- plugin is initialized
- app-layer are registered (and then keywords, and then outputs)
So the plugin init cannot call directly its app-layer registration.
Instead, it registers a callback that will be called during app-layer registration...
There was a problem hiding this comment.
Example plugin at https://github.com/catenacyber/suricata-zabbix ;-)
I think we need some minimal in-tree so we can make sure it works. For example, this is the reason why examples/plugins/ci-capture/ exists - however we also now have 2 in-tree capture methods that are plugins as well.
|
Replaced by #12110 |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5053
Describe changes:
#12060 with profiling fix and clean history
Example plugin at https://github.com/catenacyber/suricata-zabbix