rust/applayer - derive utility functions for app-layer event enums - v7 #5579
Conversation
The derive macro will implement this trait for app-layer event enums.
Currently has one derive, AppLayerEvent to be used like:
pub enum DNSEvent {
MalformedData,
NotRequest,
NotResponse,
ZFlagSet,
}
Code will be generated to:
- Convert enum to a c type string
- Convert string to enum variant
- Convert id to enum variant
Provide generic functions for get_event_info and get_event_info_by_id. These functions can be used by any app-layer event enum that implements AppLayerEvent. Unfortunately the parser registration cannot use these functions directly as generic functions cannot be #[no_mangle]. So they do need small extern "C" wrappers around them.
Add generation of wrapper functions for get_event_info and get_event_info_by_id to the derive macro. Eliminates the need for the wrapper method to be created by the parser author.
Implementations are not required if they're just going to return -1. We allow None to be registered for that.
| } | ||
|
|
||
| /// Transform names such as "OneTwoThree" to "one_two_three". | ||
| pub fn transform_name(in_name: &str) -> String { |
There was a problem hiding this comment.
Does it make sense to use something like https://crates.io/crates/Inflector here?
There was a problem hiding this comment.
Not too big of a fan of pulling in a dependency to solve something that can be done pretty easily in a function or 2.
| /// | ||
| /// Example usage (DNS app-layer events): | ||
| /// | ||
| /// #[derive(AppLayerEvent)] |
There was a problem hiding this comment.
Maybe add a rust/derive/tests/test.rs to demonstrate and test.
There was a problem hiding this comment.
Yeah, docs/examples need a little more detail.
jasonish
force-pushed
the
derive-app-event/v7
branch
from
23e1694 to
bf5cf81
Compare
| proc-macro = true | ||
| path = "@e_rustdir@/derive/src/lib.rs" | ||
|
|
||
| [dependencies] |
There was a problem hiding this comment.
are these build dependencies only? Or do they end up in the compiled bin?
There was a problem hiding this comment.
They are build only, but can't be labeled as [build-dependencies]. Within the scope of the derive crate, they are runtime dependencies, but only used by Suricata at a build time.
However, it doesn't appear the derive crate can be labeled as a build-dependency either, however, it does not end up in the output binary. Instead the derive crate is compiled and loaded by the compiler as a "compiler" plugin. This becomes more visible in a cross compile scenario. The derive plugin would be compiled for the host environment, not the target environment.
Even though they already show up in our dependency tree, nothing triggers their usage yet so they will be new crates that we vendor. They're rather ubiquitous for anyone building procedural macros.
There was a problem hiding this comment.
The last sentence on whether they will show up in the vendored crates is a bit unclear to me. Will they be included, but not end up in the compiled bin?
There was a problem hiding this comment.
They will be included in our vendor directory, compiled and run, but not in the output binary. However, their output (the generated code) will be in our output binary if that makes sense.
Much like the output of yacc, but where yacc is compiled and run as part of the build.
|
Updated version at #6318. |
As user can be not the first parameter Bug OISF#5579
Pgsql's parameters - for message types like StartupMessage and ParameterStatus, for instance, don't have a finite, definitive set, as per their documentation. Our json schema was allow expecting a fixed set of parameters, though, resulting in SV tests failing if different, valid parameters appeared. Bug OISF#5579
For StartupMessages, the database parameter is optional. This moves the parameter into the optional_parameters list. Bug OISF#5579
Since we've done some changes to how the parameters are parsed, add one more test case to check that. Bug OISF#5579
Since we've done some changes to how the parameters are parsed, add one more test case to check that. Bug OISF#5579
As user can be not the first parameter Bug OISF#5579
Pgsql's parameters - for message types like StartupMessage and ParameterStatus, for instance, don't have a finite, definitive set, as per their documentation. Our json schema was allow expecting a fixed set of parameters, though, resulting in SV tests failing if different, valid parameters appeared. Bug OISF#5579
For StartupMessages, the database parameter is optional. This moves the parameter into the optional_parameters list. Bug OISF#5579
Since we've done some changes to how the parameters are parsed, add one more test case to check that. Bug OISF#5579
As user can be not the first parameter Bug OISF#5579
Pgsql's parameters - for message types like StartupMessage and ParameterStatus, for instance, don't have a finite, definitive set, as per their documentation. Our json schema was allow expecting a fixed set of parameters, though, resulting in SV tests failing if different, valid parameters appeared. Bug OISF#5579
For StartupMessages, the database parameter is optional. This moves the parameter into the optional_parameters list. Bug OISF#5579
Since we've done some changes to how the parameters are parsed, add one more test case to check that. Bug OISF#5579
This PR shows how we can use a Rust procedural macro to derive AppLayer event functions from an emum.
Given an enum like:
supporting code will be added allowing the protocol to register
get_event_infoandget_event_info_by_idcallbacks like:All the parser needs to do is enumerate the different events, the macro will take care of generating the support code.
Redmine issue:
https://redmine.openinfosecfoundation.org/issues/4154
Previous PR:
#5501
Changes from last PR: