On Thu, Jan 02, 2014 at 02:03:03PM +0100, Jan Kratochvil wrote:
> Did you discuss this with the kernel hackers?
Not yet. The discussions above suggest there should exist a solution with
user-accessible /proc/PID/map_files/ but it is not easy to make it security
safe and as root-only access was sufficient for the use case that time
(=feature checkpoint/restore, whatever that means) they kept it that way.
With a plan to relax the security permissions in the future.
So far I (obviously) also do not see some obvious solution for the kernel
security issue so while I may/will work on it the kernel security permissions
extension will take some time.
It would be good to know what the permissions to access them would need
to be. A root-only solution doesn't sound too attractive to me. And if
it is ptrace attached based we might also be able to do come up with
something that extracts the ELF images from /proc/PID/mem instead (which
would have the advantage of being usable on more kernels).
> I think it is useful to implement this for /proc/PID/exe first
> that works extend it to /proc/PID/map_files if the permission and
> security concerns can be addressed by the kernel people. /proc/PID/exe
> seems to be available everywhere, while /proc/PID/map_files looks very
I do not think /proc/PID/exe will make the long-term running live processes
unwinding more useful. Even if the unwind does not fail on the executable
itself there is even higher probability the unwind fails on any of the shared
libraries present in the backtrace.
It is just a small step that lets you experiment more easily with the
module report code in the same way as /proc/PID/map_files might work.
Assuming the security permissions are the same.
> I am slightly concerned by the fact that gdb doesn't seem to
> mechanism yet. We should at least coordinate usage of this kernel
> feature with them.
I have filed it for GDB in the meantime:
Linux /proc/PID/map_files/ for deleted files
> Ideally gdb experiments a bit with it and when they
> have found all the quirks we can use it properly :)
This still will leave elfutils unwinder unusable for general (=even long-term
running) live process unwinding.
Sure, but it would be silly to have a mechanism that works for elfutils
eu-stack but then not being able to use the same mechanism with gdb. It
really should work for both. So we really should coordinate.