[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Where has GETSIGINFO gone?

Hi all,

I was somewhat surprised to find in LWN a message, posted to this list[1], suggesting that a project of mine, fakeroot-ng, is a potential beneficiary of utrace. Truth be told, all utrace has offered me so far is pain.

In particular, when working with ptrace to perform generic virtualization, one runs against an interesting problem. The core ptrace interface is notifying the debugger about events delivered at the debuggee. Whenever "interesting" events are reported (such as single step or a system call), this appears to the debugger to be a SIGTRAP delivered at the debugee process. Particularly for system calls tracing, the debugger needs to keep track over how many times it was notified, as it will get two notifications for each system call - one upon entry and one upon exit. I'm fairly sure that I'm not saying anything which is news to almost everyone on this list.

The problem is that, as a debugger, I need to be able to differentiate between a SIGTRAP supposedly delivered to the debuggee because I asked to trace the system calls, and a SIGTRAP actually delivered to the debuggee. If I don't, my count is going to be off, and I will totally mis-interpret the debugee's state.

The best way, as far as I can tell, to do that on Linux is to use the PTRACE_GETSIGINFO command. This provides me with a field, si_code, that can distinguish between a signal and a system call. This is important to make sure that I don't get confused over which is which.

Unfortunately, utrace (at least the version integrated into the Fedora Core 9 and Fedore 10 kernels) totally eliminated this system call. When calling ptrace with PTRACE_GETSIGINFO I get back "Invalid argument".

I've tried to figure out how other programs handle the situation. Looking at the strace sources, it seems to use a heuristics in order to try and detect this state. It relies on the fact that, on most Linux platforms, the kernel sets the return code register to -ENOSYS before calling the syscall enter ptrace hook, and tries to detect spurious SIGTRACE if the value is not set. This solution has numerous deficiencies:
  • It is platform specific. On PowerPC, for example, the kernel does not, and strace has no way of telling the two cases apart.
  • It is non-reliable. The check can only be made on the syscall enter hook, not the exit hook.
  • It relies on internal kernel behavior
  • It is easy to fool by a malicious programmer. For example, send the signal from another process, have the first process do a tight loop where EAX (or whatever) is set to -ENOSYS, and strace will think you have entered a random system call, probably the last one again. Do that right after a fork or an exec, and all sorts of fun stuff will happen.
Since I'm aiming to use the fakeroot-ng technology for security related stuff (not in fakeroot-ng - I intend to split the project), these drawbacks are fatal.

Don't get me wrong. I think cleaning up the debugger interfaces inside the kernel is an excellent idea. I just don't think breaking user space compatibility over the old interface, broken though you might think it is, is justified. This is directed not so much against the utrace project as it is against RedHat including it in production kernels.


[1] - http://www.redhat.com/archives/utrace-devel/2009-March/msg00112.html
Shachar Shemesh
Lingnu Open Source Consulting Ltd.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]