Support more than 38 override matchActions on LSM function

[holyspectral]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your feature request related to a problem?

Currently the override action of kprobe sensors on LSM functions are based on fmod_ret eBPF programs. This feature is great because it allows users to write rules based on the arguments of LSM functions and to deny unwanted behavior. The issues like the TOCTOU race or symlink is not a problem, because LSM already handles them.

However, for this feature to be very useful, there are still some issues.

• The fmod_ret program is implemented based on eBPF trampoline. Linux kernel only allows up to 38 eBPF trampolines. That means that we can only have 38 fmod_ret programs attached by Tetragon at maximum.
• Under the current Tetragon design, for each override matchAction specified on lsm functions, a fmod_ret program is created and attached by Tetragon. That means when a new policy is created on the same LSM function, a new fmod_ret programs will still be created and take a seat of eBPF trampolines.

For example, when we have two tracing policies dealing with same two LSM functions (A & B), we would have the graph below. Despite only two LSM functions used, 4 override_tasks maps will be created, and 4 seats of eBPF trampolines will be taken by generic_fmodret_override programs.

  graph TD;
      TracingPolicy1-->singleKprobeSensor1;
      TracingPolicy1-->singleKprobeSensor2;
      singleKprobeSensor1-->map1[(override_tasks on A function)];
      singleKprobeSensor2-->map2[(override_tasks on B function)];
      map1-->fmod_ret1[generic_fmodret_override on A function]
      map2-->fmod_ret2[generic_fmodret_override on B function]

      TracingPolicy2-->singleprobeSensor3;
      TracingPolicy2-->singleKprobeSensor4;
      singleprobeSensor3-->map3[(override_tasks on A function)];
      singleKprobeSensor4-->map4[(override_tasks on B function)];
      map3-->fmod_ret3[generic_fmodret_override on A function]
      map4-->fmod_ret4[generic_fmodret_override on B function]

Describe the feature you would like

We would like to have more than 38 policies to override return values on lsm functions.

Describe your proposed solution

I think we can allow each policy to share generic_fmodret_override program and related maps, as long as they're attached to the same function.

By sharing the generic_fmodret_override program, the flow would become like the below, where only two maps are needed and two seats of eBPF trampolines are used, compared to the current design:

  graph TD;
      TracingPolicy1-->singleKprobeSensor1;
      TracingPolicy1-->singleKprobeSensor2;
      singleKprobeSensor1-->map1[(override_tasks on A function)];
      singleKprobeSensor2-->map2[(override_tasks on B function)];

      TracingPolicy2-->singleKprobeSensor3;
      TracingPolicy2-->singleKprobeSensor4;
      singleKprobeSensor3-->map1[(override_tasks on A function)];
      singleKprobeSensor4-->map2[(override_tasks on B function)];

      map1-->fmod_ret11[generic_fmodret_override on A function]
      map2-->fmod_ret12[generic_fmodret_override on B function]

This should reduce both the memory utilization from the override_tasks map, and the ebpf trampolines seats used by override matchActions.

This is just an idea right now and I'm trying to do a POC. Any comment is welcome!

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[olsajiri]

looks good, we could probably share override_tasks map and have just single override program attach for a function.. I will need to check how could we kick the sensor hierarchy to support this, perhaps with the symbolic links

[holyspectral]

@mtardy thanks for merging #4158 ! I'm still working on this issue via #4244 . Could you please keep this one open?

[mtardy]

@mtardy thanks for merging #4158 ! I'm still working on this issue via #4244 . Could you please keep this one open?

Ah maybe do not add Fixes: next time if it's just the first step, maybe Partially fixes or something like that :)!

[holyspectral]

Ah maybe do not add Fixes: next time if it's just the first step, maybe Partially fixes or something like that :)!

My bad. I will make sure they reflect the correctr status next time. Thanks for the reminder!

[mtardy]

Ah maybe do not add Fixes: next time if it's just the first step, maybe Partially fixes or something like that :)!

My bad. I will make sure they reflect the correctr status next time. Thanks for the reminder!

no worry, it's just that it automatically closes issue then, thank you for the patches :)