On Thu, Nov 9, 2017 at 10:13 AM, Kaiwan N Billimoria
<kaiwan.billimo...@gmail.com> wrote:
>> But I don't know if there is anything else than the profiling code
>> that _really_ wants access to /proc/kallsyms in user space as a
>> regular user.
>
Front-ends to ftrace, like trace-cmd?
[from the trace-cmd git repo (Steve Rostedt, pl stand up, pl stand up :-)
Documentation/trace-cmd-restore.1.txt :
...
*-k* kallsyms::
Used with *-c*, it overrides where to read the kallsyms file from.
By default, /proc/kallsyms is used. *-k* will override the file to
read the kallsyms from. This can be useful if the trace.dat file
to create is from another machine. Just copy the /proc/kallsyms
file locally, and use *-k* to point to that file.
...
]
> Am unsure about this, but kprobes? (/jprobes/kretprobes), and by
> extension, wrappers over this infra (like SystemTap)?
> I (hazily) recollect a script I once wrote (years back though) that
> collects kernel virtual addresses off of kallsyms for the purpose of
> passing them to a 'helper' kernel module that uses kprobes. I realize
> that 'modern' kprobes exposes APIs that just require the symbolic name
> & that they're anyway at kernel privilege... but the point is, a
> usermode script was picking up and passing the kernel addresses.
>
> Also, what about kernel addresses exposed via System.map?
> Oh, just checked, it's root rw only.. pl ignore.
