On Mon, 2020-11-30 at 18:41 -0800, Alexei Starovoitov wrote: > On Mon, Nov 30, 2020 at 05:23:22PM +0100, Florent Revest wrote: > > On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote: > > > Looks like debug-only helper. > > > I cannot think of a way to use in production code. > > > What program suppose to do with that string? > > > Do string compare? BPF side doesn't have a good way to do string > > > manipulations. > > > If you really need to print a symbolic name for a given address > > > I'd rather extend bpf_trace_printk() to support %pS > > > > We actually use this helper for auditing, not debugging. > > We don't want to parse /proc/kallsyms from userspace because we > > have no guarantee that the module will still be loaded by the time > > the event reaches userspace (this is also faster in kernelspace). > > so what are you going to do with that string? > print it? send to user space via ring buffer? We send our auditing events down to the userspace via a ring buffer and then events are aggregated and looked at by security analysts. Having the symbol and module names instead of a hex address makes these events more meaningful. > Where are you getting that $pc ? I give an example in the commit description: we hook into callback registration functions (for example, nf_register_net_hook), get the callback address from the function arguments and log audit information about the registered callback. For example, we want to know the name of the module in which the callback belongs and the symbol name also helps enrich the event.
