|
From: Paul O. <or...@3m...> - 2010-10-25 14:57:23
|
Hi, I have filed an Ubuntu bug after being unable to use --db-attach=yes feature of valgrind. https://bugs.launchpad.net/bugs/665850 It looks like this feature has been destroyed "by design": https://wiki.ubuntu.com/Security/Features#ptrace https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection This new hardened behaviour can be deactivated by modifying /proc/sys/kernel/yama/ptrace_scope which is then global and not really pretty solution. Does anybody have suggestion how to fix the problem in user space? I can easily imagine scenario where I would need to use valgrind with debugger on a machine, where I have no root access. Thanks, Paul |
|
From: Tom H. <to...@co...> - 2010-10-25 15:14:19
|
On 25/10/10 15:57, Paul Ortyl wrote: > I have filed an Ubuntu bug after being unable to use --db-attach=yes feature > of valgrind. > https://bugs.launchpad.net/bugs/665850 > > It looks like this feature has been destroyed "by design": > https://wiki.ubuntu.com/Security/Features#ptrace > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection > > This new hardened behaviour can be deactivated by modifying > /proc/sys/kernel/yama/ptrace_scope > which is then global and not really pretty solution. As I read that, you can still ptrace your own descendants (which is what valgrind does) just not other processes owned by the same user. So I think the diagnosis you were given may be wrong. That said, the db-attach feature is very fragile and often fails and I would generally advise only trying to use it as a last resort - it is normally quite possible to find and fix problems without it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: WAROQUIERS P. <phi...@eu...> - 2010-10-25 15:18:36
|
>Does anybody have suggestion how to fix the problem in user space? > >I can easily imagine scenario where I would need to use >valgrind with debugger >on a machine, where I have no root access. You might try the gdbserver patch (http://bugs.kde.org/show_bug.cgi?id=214909) With this patch, if you invoke the vgdb relay application with --max-invoke-ms=0, then no usage of ptrace is done. In addition, it provides a fully debuggable process under valgrind E.g. you can put breaks, look at threads, call code from gdb, modify variables, invoke various valgrind tool client requests at any point (memleak search, make some memory defined or undefined, ...) ... (the only drawback of --max-invoke-ms=0 is that you cannot connect to the valgrind process to debug if it is blocked in a system call). Note that the usage is slightly different of --db-attach=yes: You must give --vgdb=yes arg to valgrind and then you start a gdb in another window and do: gdb <your executable> target remote | vgdb --max-invoke-ms=0 --vgdb=yes valgrind arg indicates to run an gdbserver embedded in valgrind. The gdb target remote command above will "connect" to this gdbserver. For more info, you can read coregrind/m_gdbserver/README_DEVELOPPERS or do valgrind --help or (inside gdb, when connected) use: monitor help (the embedded valgrind gdbserver will provide a help for the requests it understands). ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Paul O. <or...@3m...> - 2010-10-25 17:19:31
|
On Monday 25 October 2010 17:14:06 Tom Hughes wrote: > On 25/10/10 15:57, Paul Ortyl wrote: > > I have filed an Ubuntu bug after being unable to use --db-attach=yes > > feature of valgrind. > > https://bugs.launchpad.net/bugs/665850 > > > > It looks like this feature has been destroyed "by design": > > https://wiki.ubuntu.com/Security/Features#ptrace > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Pro > > tection > > > > This new hardened behaviour can be deactivated by modifying > > /proc/sys/kernel/yama/ptrace_scope > > which is then global and not really pretty solution. > > As I read that, you can still ptrace your own descendants (which is what > valgrind does) just not other processes owned by the same user. > > So I think the diagnosis you were given may be wrong. Unfortunately it is not how valgrind+gdb do that. See the bug description I posted at launchpad. > That said, the db-attach feature is very fragile and often fails and I > would generally advise only trying to use it as a last resort - it is > normally quite possible to find and fix problems without it. Normally if I get valgrind warning it is a really obscure situation, where only the inspection of variables on the stack may reveal the truth... I hope that there is some kind of solution, but frankly I do not see any. The GDB gets started as a child of valgrind, but GDB is not parent of the process, which should get monitored. So unless there is a clever trick I do not know how to get around this security feature which is a complete show stopper on a developers machine without root access. Paul |
|
From: Tom H. <to...@co...> - 2010-10-25 17:53:20
|
On 25/10/10 18:17, Paul Ortyl wrote: > On Monday 25 October 2010 17:14:06 Tom Hughes wrote: > >> As I read that, you can still ptrace your own descendants (which is what >> valgrind does) just not other processes owned by the same user. >> >> So I think the diagnosis you were given may be wrong. > > Unfortunately it is not how valgrind+gdb do that. See the bug description I > posted at launchpad. Ah right I understand now - it's gdb that can't attached. I was thinking that it was valgrind that was failing to attach - the debugger stuff works by valgrind cloning the child and using ptrace to control the cloned process you see. > I hope that there is some kind of solution, but frankly I do not see any. > The GDB gets started as a child of valgrind, but GDB is not parent of the > process, which should get monitored. So unless there is a clever trick I do > not know how to get around this security feature which is a complete show > stopper on a developers machine without root access. Well I think that "feature" needs to be turned off on a development machine - that can be done permanently by an admin if developers don't have root access. It's not only valgrind that is broken by this, you won't be able to attach gdb to a running process either, which is a fairly common thing for a developer to want to do. This feature may be fine for production machines, especially internet exposed ones, but probably not for development machines. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |