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

[Auditbeat] Socket: Support maxactive in kretprobes #20327

Closed
1 of 2 tasks
adriansr opened this issue Jul 29, 2020 · 4 comments
Closed
1 of 2 tasks

[Auditbeat] Socket: Support maxactive in kretprobes #20327

adriansr opened this issue Jul 29, 2020 · 4 comments
Labels
Auditbeat help wanted Indicates that a maintainer wants help on an issue or pull request meta Stalled

Comments

@adriansr
Copy link
Contributor

adriansr commented Jul 29, 2020

Kretprobes (kprobes that fire on function return) have one parameter called maxactive:

maxactive - The maximum number of instances of the probed function
that can be active concurrently. For example, if the function is non-
recursive and is called with a spinlock or mutex held, maxactive = 1
should be enough. If the function is non-recursive and can never
relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should
be enough. maxactive is used to determine how many kretprobe_instance
objects to allocate for this particular probed function. If maxactive
<= 0, it is set to a default value (if CONFIG_PREEMPT
maxactive=max(10, 2 * NR_CPUS) else maxactive=NR_CPUS)

Originally this parameter was only available to kprobes set by the kernel. Starting in Linux v4.12+, it is exposed in the kprobe_events file (commit).

The socket dataset is not aware of this parameter, so it's using the default value for it. As a side effect of this value being exposed in kprobe_events, Auditbeat is unable to uninstall it's own kretprobes, because it's expecting the entries to start with r: while they are rNN: where NN is the maxactive value.

We should:

@adriansr adriansr added meta help wanted Indicates that a maintainer wants help on an issue or pull request Auditbeat labels Jul 29, 2020
@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Jul 29, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/siem (Team:SIEM)

@botelastic botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Jul 29, 2020
@botelastic
Copy link

botelastic bot commented Jun 30, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

@botelastic
Copy link

botelastic bot commented Oct 25, 2022

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

@botelastic botelastic bot added the Stalled label Oct 25, 2022
@botelastic botelastic bot closed this as completed Apr 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Auditbeat help wanted Indicates that a maintainer wants help on an issue or pull request meta Stalled
Projects
None yet
Development

No branches or pull requests

2 participants