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 v1 #11321

Closed
wants to merge 6 commits into from

Conversation

catenacyber
Copy link
Contributor

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

Describe changes:

  • App-layer plugins

Comes after merge of #11291

Draft to get general feedback
especially the use of ALPROTO_DYNAMIC_NB

Still todo: supply an example of an app-layer plugin

catenacyber and others added 6 commits June 18, 2024 10:08
So that we can have dynamically registered protocols.
Doing it at compile time, with CFLAGS=-DALPROTO_DYNAMIC_NB=1,
allows to keep the rest of the code using ALPROTO_MAX

Ticket: 5053
Copy link

codecov bot commented Jun 18, 2024

Codecov Report

Attention: Patch coverage is 25.84270% with 66 lines in your changes missing coverage. Please review.

Project coverage is 77.67%. Comparing base (49ecf37) to head (a01b68d).
Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11321      +/-   ##
==========================================
- Coverage   82.47%   77.67%   -4.80%     
==========================================
  Files         934      934              
  Lines      252270   252235      -35     
==========================================
- Hits       208055   195920   -12135     
- Misses      44215    56315   +12100     
Flag Coverage Δ
fuzzcorpus ?
livemode 18.76% <7.86%> (+<0.01%) ⬆️
pcap 43.73% <25.84%> (-0.05%) ⬇️
suricata-verify 61.30% <25.84%> (-0.02%) ⬇️
unittests 59.90% <7.86%> (-0.02%) ⬇️

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

@jasonish
Copy link
Member

Do you see new "built-in" app-layers going through this API? Or still using a static assignment?

@catenacyber
Copy link
Contributor Author

Do you see new "built-in" app-layers going through this API? Or still using a static assignment?

still static...

@suricata-qa
Copy link

ERROR:

ERROR: QA failed on build_asan.

Pipeline 21127

@victorjulien
Copy link
Member

I would like to see the registration of AppProto's to be cleaner. Like in other places, we can have something like built-in app protos are static, followed by a dynamic range. _MAX would be replaced by a fully dynamic app_proto_max or something, and the arrays and other things will have to be replaced by more dynamic data structures.

@victorjulien
Copy link
Member

AppProto as an enum also isn't a great fit anymore, it's more just a registered id for these dynamic cases

@@ -1776,6 +1780,15 @@ void AppLayerParserRegisterProtocolParsers(void)
} else {
SCLogInfo("Protocol detection and parser disabled for pop3 protocol.");
}
#ifdef ALPROTO_DYNAMIC_NB
Copy link
Member

Choose a reason for hiding this comment

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

This would not be something that should be compile time optional?

@jasonish
Copy link
Member

Do you see new "built-in" app-layers going through this API? Or still using a static assignment?

still static...

Any particular reason? It would be nice to use these APIs for built in and dynamically loaded unless there is good reason not to.

@catenacyber
Copy link
Contributor Author

I would like to see the registration of AppProto's to be cleaner. Like in other places, we can have something like built-in app protos are static, followed by a dynamic range. _MAX would be replaced by a fully dynamic app_proto_max or something, and the arrays and other things will have to be replaced by more dynamic data structures.

There a re 33 arrays to handle, not 2 like for keywords (cf git grep '\[ALPROTO_MAX'). :-/
And I guess some of them would now need a post init stuff to realloc the array after the alprotos have been registered

Any particular reason? It would be nice to use these APIs for built in and dynamically loaded unless there is good reason not to.

Ok, it can be done in follow up works like keywords in #11316

AppProto as an enum also isn't a great fit anymore, it's more just a registered id for these dynamic cases

It is no longer the case here : `typedef uint16_t AppProto;

@victorjulien
Copy link
Member

Yeah I realize it's major effort, but I think we shouldn't hack around it, esp not in this phase of the 8 dev cycle.

@catenacyber
Copy link
Contributor Author

Some work done in #11355

@catenacyber
Copy link
Contributor Author

So, closing this draft.

#11572 is the first PR towards it

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.

4 participants