new(userspace/engine): generalize indexable ruleset #3251
Conversation
|
This PR may bring feature or behavior changes in the Falco engine and may require the engine version to be bumped. Please double check userspace/engine/falco_engine_version.h file. See versioning for FALCO_ENGINE_VERSION. /hold |
poiana
added
do-not-merge/hold
release-note-none
and removed
do-not-merge/release-note-label-needed
labels
mstemm
force-pushed
the
generalize-indexable-ruleset
branch
from
ef1fe3f to
2f5cf0c
Compare
mstemm
force-pushed
the
generalize-indexable-ruleset
branch
from
e0be57e to
8090801
Compare
| std::string::size_type pos; | ||
|
|
||
| switch(match) | ||
| std::shared_ptr<wrapper> derived = std::dynamic_pointer_cast<wrapper>(wrap); |
There was a problem hiding this comment.
A dynamic cast for every rules index bucket, for every event, seems like a bit overkill for performance to me. I like this modularization effort, but can we choose a more performant route? For example, maybe the wrapper type can be a template parameter?
There was a problem hiding this comment.
I can static_cast it instead, the wrapper will always be the derived type anyway. I switched it to static_cast.
There was a problem hiding this comment.
Ok, after a PM with you I switched indexable_ruleset to be a template instead. PTAL.
|
/milestone 0.39.0 |
mstemm
force-pushed
the
generalize-indexable-ruleset
branch
from
8090801 to
c2011ac
Compare
Now that custom rules loading implementations (and related, custom rulesets) can be swapped into falco in a customizable way, there is some functionality in evttype_index_ruleset that could be used by other rulesets, specifically the part that segregates filters by ruleset and enables/disables filters based on name substring + tags. To allow for this, create a new template indexable_ruleset<class filter_wrapper> which derives from filter_ruleset and segregates the filter_wrappers by ruleset. It also optionally segregates filter_wrappers by event type. The filter_wrapper class is an object that can return a name, tags, and sc/event codes. The main interfaces for classes that derive from indexable_ruleset are: - add_wrapper(), which provides a filter_wrapper to the indexable_ruleset. This is generally called from add()/add_compile_output(), which must be implemented by the derived class. - run_wrappers(), which must be implemented by the derived class and is called for event processing. Most of the methods required by filter_ruleset are implemented by indexable_ruleset and do not need to be implemented by the derived class. Signed-off-by: Mark Stemm <[email protected]>
Modify evttype_index_ruleset to derive from indexable_ruleset instead of having its own implementation of segregating filters by ruleset id/event type. An evttype_index_wrapper contains a falco rule and filter, and implements the methods required by the template. run_wrappers() evaluate the filter as before, without the segregation by ruleset id/event type. Signed-off-by: Mark Stemm <[email protected]>
mstemm
force-pushed
the
generalize-indexable-ruleset
branch
from
c2011ac to
d8a8a59
Compare
|
LGTM label has been added. Git tree hash: 2b16ef9e657a42a7641a0972210b87db15b5ec83
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP, jasondellaluce, mstemm The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
FedeDP
changed the title
|
/unhold |
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area engine
What this PR does / why we need it:
Now that custom rules loading implementations (and related, custom rulesets) can be swapped into falco in a customizable way, there is some functionality in evttype_index_ruleset that could be used by other rulesets, specifically the part that segregates filters by ruleset and enables/disables filters based on name substring + tags. This PR makes a base class for that. See the commit comments for more details.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NO