dnsdist: allow users to inject their own XDP program to handle dropped/redirected packets

[MiniPierre]

• Program: dnsdist
• Issue type: Feature request

Short description

Allow the XDP filter to perform user-defined logging action on dropped and redirected packets

Usecase

After the XDP filter pull request #10498, it appeared that we wanted to have the opportunity to log packets before performing DROP or TC action. As other people may have the same need but do not log the same way, logging facilities should be as modular as possible

Description

I was thinking of using a BPF_MAP_TYPE_PROG_ARRAY inside the filter that would allow users to inject their own XDP program at specific indexes (let say index 0 is for dropped packets, index 1 is for redirected packets). The XDP filter would check if any program is loaded at the given index and perform the tail call if something is found, or perform the default action if no program is found

Might be something like:

BPF_TABLE("prog", int, int, progsarray, 2);
...
//if packet is dropped
if progsarray.lookup(0) { 
  progsarray.call(ctx, 0);
}

return XDP_DROP
...
//if packet is redirected
if progsarray.lookup(1) {
  progsarray.call(ctx, 1);
}

return XDP_TX

I would be totally OK to work on such thing but I would like to know if it is something that would have any interest for dnsdist, or if it is too specific to be implemented

[rgacogne]

The feature seems very interesting! Are you considering a pinned program table, that could be updated from an external source without reloading the main XDP program, or a "local" table that will require the logging functions to be loaded by the main XDP program? Both options are fine by me, I'm just trying to better understand what you have in mind.

[MiniPierre]

I was considering a pinned table, so that we can update the loaded programs at will from an external source. Adding logging function to dnsdist for such situation might make it quite heavy for a need that is quite specific to our organization.

[rgacogne]

That makes complete sense, thanks! So yes, I would gladly merge such a feature.

[MiniPierre]

For information, it seems that map lookup are not authorized in progs array. It is not a problem as it appears that if no program is loaded at the given index, the BPF program does continue its execution, performing the remaining actions as a "default" behavior

If no eBPF program is found at the given index of the program array (because the map slot doesn't contain a valid program file descriptor, the specified lookup index/key is out of bounds, or the limit of 32 nested calls has been exceed), execution continues with the current eBPF program. This can be used as a fall-through for default cases.
Ref: https://www.systutorials.com/docs/linux/man/2-bpf/