Date: Sun, 03 Dec 2006 01:36:29 +0100 From: Stanislav Ochotnicky <stanislav.ochotnicky@kmit.sk> To: freebsd-hackers@freebsd.org Subject: Re: tracing AND intercepting syscalls? Message-ID: <45721C0D.2000101@kmit.sk> In-Reply-To: <20061202194840.GD35681@deviant.kiev.zoral.com.ua> References: <4571AA86.1060303@kmit.sk> <20061202194840.GD35681@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Kostik Belousov wrote: > On Sat, Dec 02, 2006 at 05:32:06PM +0100, Stanislav Ochotnicky wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi >> >> I'm doing some research concerning tracing and intercepting of syscalls. >> Ideally this would be done in userspace. It doesn't have to be >> system-wide. It would be enough if I could fork/exec new process, and >> somehow be noticed every time it makes syscall, with ability to alter >> arguments/return values. I (more or less) need similar interface like >> linux ptrace when called with PTRACE_SYSCALL. systrace utility does the >> same thing in OpenBSD/linux. I've been through some mailing lists and >> their archives, read FreeBSD developers guide,TrustedBSD's MAC framework >> intro, man pages, asked on IRC and god knows what else and couldn't find >> a solution. Here's what I have found out so far about interfaces that >> resemble what I need: >> >> ptrace: unable to trace syscalls, only singlestep, this would be too >> slow imho, not mentioning problems with identifying syscalls. >> > Did you look at PT_SYSCALL, PT_TO_SCE and PT_TO_SCX ptrace(2) facilities ? Cant believe I missed them, although they are not in man page of ptrace. At least on my FreeBSD 6.1. Citing from http://www.freebsd.org/projects/ideas/ "Someone needs to finish the support for PT_SYSCALL in the ptrace() subsystem, and add support for another ptrace() command that will replace the PIOCWAIT and PIOCSTATUS ioctls of procfs (should probably be named PT_WAIT), in order for truss(1) to be able to work without procfs(5). Removing the procfs(5) dependency from ps -e is also desirable." But I'll have a look. >> /proc interface: more or less like ptrace, better with modifying memory >> of process etc. but also unable to trace syscalls > Read the man pages and code of the truss(1) and strace(1) utilities. > Truss is available in base system, strace is in the ports. > Truss is a no way because it can't intercept syscalls. But I really don't understand how I could miss strace, since it's available also on other OSes. Will definitely look into it. Since it's done in userspace, there has to be a way(even if it would be obscure), for me to do the same.Maybe it uses mentioned PT_SYSCALL or such. Anyway this will be enough for me to start. Thanks a lot. >> ktrace: almost there, able to trace syscalls, but it only writes them to >> file, and thus i cannot intercept them. >> >> trustedbsd's MAC framework: i've read manual, looked at source etc. And >> I couldn't find a way to stop at every syscall certain process has made. >> There is mac_syscall() function but as far as I could tell, it only >> registers new syscall. All in all, it seems that it should have some way >> to do this, maybe I just couldn't find it. >> >> If kernel module/change is needed I would appreciate push in right >> direction. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFchwNul7h5FTXf/MRCPkUAJ9gSCjlHd0NFY76p4/eWq+OMoXHEgCeNVAZ AutEBjcAdcvswiYHEC9CdhM= =OWZG -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45721C0D.2000101>