-
Notifications
You must be signed in to change notification settings - Fork 165
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
Support execve
exit events and clone
child exit events on ARM64
#416
Conversation
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
We implemented this tracepoint to catch `execve` exit events on `arm64` Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Removing this check, we can compile out fillers that are not used in that specific architecture Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
This tracepoint catches `clone` child exit events on `arm64` Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
This tracepoint catches `execve` exit events on `arm64` Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
This tracepoint catches `clone` child exit events on `arm64` Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
We are not interested in catching information about kernel threads Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
I removed the |
What about adding a README section with supported architectures and their kernel versions requirements for probe and kmod? |
I will open another PR, with also a |
This is the related pull request -> #421 |
execve
exit events and clone
child exit events on ARM64
execve
exit events and clone
child exit events on ARM64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: a3b9f13fa4f2464e93f57d41d72e82d8f63d146d
|
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
/test build-libs-bundled-deps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: 813e46e1d98b6cb7a22dcdfbe0eddc61d0608360
|
if(pidns_level != 0) | ||
{ | ||
flags |= PPM_CL_CHILD_IN_PIDNS; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the end, we want to detect every child that is spawned in a PID namespace different from the init one so we can keep only this logic in the if
statement
Hi @gnosek, are these changes ok for you? |
CC @jcpittman144, PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP, gnosek 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 |
…falcosecurity#93) - Falcosecurity/libs falcosecurity#416: Support execve exit and clone child exit events on ARM64 - Falcosecurity/libs falcosecurity#418: Enable 64BIT_ARGS_SINGLE_REGISER on ARM64 - Also, disable userspace workarounds ARM, which attempted to compensate for the missing execve/clone exit events
What type of PR is this?
/kind bug
/kind feature
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area libscap-engine-bpf
What this PR does / why we need it:
This PR wants to fix a known problem regarding
ARM64
architecture, described here in this thread of the kernel mailing list. In a nutshell theexeve
exit event is not traced by thesyscalls:sys_exit
tracepoint and same thing for theclone
child exit event. These 2 events are really important for the state of the so we implemented this workaround to catch this 2 missing events. We have instrumented 2 new tracepoints:sched_proc_exec
to catch theexecve
exit events. This tracepoint sends the same eventPPME_SYSCALL_EXECVE_19_X
to userspace, so the consumer won't notice any difference. This new tracepoint calls a new filler that is really similar to our actualproc_startupdate
filler.sched_proc_fork
to catch theclone
child exit events. Again we send the same eventPPME_SYSCALL_CLONE_20_X
and we have a new filler. The only change seen by userspace is that the clone child exit event will be received before the clone parent exit event, but this shouldn't be a problem sincelibsinsp
already has the code to manage this situation.Some important notes:
x86
)flags
information so param number16
is always0
.euid
andguid
directly from the task struct without relating them to the user namespace (param numbers17
and18
)clone3
the child exit event will be of typeclone
and notclone3
because we are not able to distinguish kernel side which syscall has been called. In the end, this doesn't change so much since the 2 events follow the same path both kernel side and userspace side.fork
andvfork
are not defined inARM64
so we don't lose information.execve
orclone
syscalls fail, we catch the exit events with oursys_exit
tracepoint as usual, so we don't lose information at all in this case.Compatibility:
>=4.17
since we need bpfraw_tracepoints
programs to catch this new information. We lose 3 supported versions (x86
support BPF starting from4.14
) but we have no alternatives with this approach. If we want to support them we have to usekprobes
.>=3.4
sincesched/sched_process_exec
is available only kernels >=3.4
Kernel engineers are working to find solution as you can see here , in the meanwhile this could be a possible solution, let me know what to you think about that.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Next steps:
test
commits since they are only useful to test the new patch (I removed the DCO from them, so we cannot merge the PR)--> One last note
We compiled out also the
page_fault
tracepoints both from BPF and kernel module since they are not supported onARM64
Does this PR introduce a user-facing change?: