Leonardo Di Giovanna

As we are approaching the end of https://github.com/falcosecurity/libs/issues/2427, I would like to revamp this discussion with some thoughts. As briefly discussed in the mentioned issue and on this issue, the...

> I think which ever way we choose to go, it would most likely be beneficial to also have an option for the user to disable mitigation in which case...

> Only random thought, but do we need to send the original value to the user level what if we just store the original value in a temp buffer upon...

I tried to scratch something based on the first approach mentioned [in my comment](https://github.com/falcosecurity/libs/issues/2407#issuecomment-3047869843): > 1. using some kind of hash map storing the association between the current thread TID...

Yes, that code path is already handling the possible absence of the enter event. I still need to manage some corner case related to https://github.com/falcosecurity/libs/pull/2068, but after this (since nobody...

I want to recap here my new findings related to implementing the original solution using tracepoints in the modern probe: - tracepoints programs, attached to `syscalls/sys_enter_*`, are not triggered for...

After some attempts, I realized that using a single fentry program is not the right way to move forward, as it can still be vulnerable to fentry-related bugs in old...

I guess the problem here is related to SLES 15 SP4 limiting the tid range. I'm noticing that the tids are set to values greater than 32768... From [this article](https://www.suse.com/support/kb/doc/?id=000020429)...

I don't see any problem with lowering them, but maybe there is some reason why they are set to those specific values. An alternative would be to programmatically lower those...

> I agree, we could write a small get_test_pid helper that does exactly that, and we should be good to go. Yes, I think we can proceed with this.