Added by Jason Ish 26 days ago. Updated 20 days ago.
Description
An API "handle" should be exposed to trigger rule and tenant reloads.
A good test for this is to make Suricata use this API itself, for when reloads are triggered over the Unix socket.
Ideally done in a way suitable for backport to 8.0.
I think in Suricata currently there is a mix of detect engine logic and threading when doing reloads:
- we reload the config, but populate the new values under a special namespace in the config api (kind of thread unsafe btw, as the conf api has no threading awareness)
- we setup a new DetectEngineCtx with the new config values
- we create a new DetectEngineThreadCtx for each worker thread
- we pointer swap the DetectEngineThreadCtx for each of the worker threads
- now we need to wait for each worker thread to actually complete using the old DetectEngineThreadCtx. In busy traffic this happens quickly, but on a (mostly) idle system worker threads may be blocked in their capture methods. So we break-loop these if needed.
- finally we free the old DetectEngineThreadCtx instances and the DetectEngineCtx
We should probably first untangle this for Suricata itself before we can have API's for it?
Should we start with killing the config api hack and load a new config into a variable and pass that around in the Detect engine API? Could probably become a member of the DetectEngineCtx object.
edit: this should probably it's own ticket
We should probably first untangle this for Suricata itself before we can have API's for it?
Should we start with killing the config api hack and load a new config into a variable and pass that around in the Detect engine API? Could probably become a member of the DetectEngineCtx object.
To start, I want function handles that can be called that accomplish the same functionality that is available from the Unix socket, in a format that can be backported to 8, as we have a need there as well.