Prev: [PATCH 6/6 v2]afs:fsclient.c Fix variable 'bp' set but not used
Next: [RFC][PATCH] PM: Avoid losing wakeup events during suspend
From: Martin Mares on 19 Jun 2010 18:10
Hello, world!\n

I am playing with a simple ptrace-based sandbox for use in programming
contest (see git://git.ucw.cz/moe.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 http://dunedin.lug.net.nz/forums/showthread.php?t=325963).
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 <mj(a)ucw.cz> http://mj.ucw.cz/
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 6/6 v2]afs:fsclient.c Fix variable 'bp' set but not used
Next: [RFC][PATCH] PM: Avoid losing wakeup events during suspend