[lkml]   [2010]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectTracing of syscalls on x86
Hello, world!\n

I am playing with a simple ptrace-based sandbox for use in programming
contest (see git://, box/box.c). It works pretty well
on the i386, but I got stuck when porting it to amd64.

The problem is that anytime ptrace reports a system call, I do not know how
to determine whether it is a 32-bit syscall or a 64-bit one -- both sets
of syscalls use different numbering, but they seem to be reported in exactly
the same way. For example, when a 64-bit process uses int 0x80 to issue
a 32-bit syscall, it cannot be distinguished from the same process using
the syscall instruction for a 64-bit syscall.

The same problem was present in auditing of syscalls, but it got fixed
in 2008 by Michael Davidson (see
The auditing code path now checks the TS_COMPAT flag, which faithfully
represents the real syscall type. However, I do not see any possibility
of reading this flag from user space.

The strace utility currently checks the CS register to determine whether
the process runs in 32- or 64-bit mode, which is wrong (in case of int 0x80
issued in 64-bit mode). It also contains commented-out code which tries
to check the instruction code immediately preceding the current EIP,
which is ugly and potentially unreliable (as we do not have a pointer
to the start of the instruction, so that the detection might be fooled
by one instruction code being a suffix of another; it does not seem
to happen on current CPU's, but it could in the future).

Is there anything I have overlooked?

If not, would you welcome a patch allowing to read TS_COMPAT from user space?

Have a nice fortnight
Martin `MJ' Mares <>
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Lisp Users: Due to the holiday, there will be no garbage collection on Monday.

 \ /
  Last update: 2010-06-20 00:05    [W:0.041 / U:1.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site