linux-kernel - Tracing of syscalls on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <mj+md-20100619.213111.21845.nikam@ucw.cz>
Date:	Sat, 19 Jun 2010 23:52:30 +0200
From:	Martin Mares <mj@....cz>
To:	linux-kernel@...r.kernel.org
Subject: Tracing of syscalls on x86

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@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/