Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.1605050058590.14322@monopod.intra.ispras.ru>
Date: Thu, 5 May 2016 01:54:12 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: ptrace addr2 weirdness

I was eyeballing musl's ptrace syscall wrapper and noticed it passes an extra
argument to the kernel:

long ptrace(int req, ...)
{
[snip]
	va_start(ap, req);
	pid = va_arg(ap, pid_t);
	addr = va_arg(ap, void *);
	data = va_arg(ap, void *);
	addr2 = va_arg(ap, void *);
	va_end(ap);

	if (req-1U < 3) data = &result;
	ret = syscall(SYS_ptrace, req, pid, addr, data, addr2);
[snip]
}

The last argument is completely undocumented in the Linux manpage and if you
look at generic kernel source you'll find that the syscall indeed only looks
at four arguments, req, pid, addr, data. Turns out the fifth 'addr2' argument
is used on sparc with PTRACE_{READ,WRITE}{DATA,TEXT} requests, but given that
musl neither supports sparc, nor (correctly) exposes those request kinds in
sys/ptrace.h, this argument passing is unnecessary, puzzling, and can be
either removed or at least a comment would be nice :)

The reason I was eyeballing it is to see how the variadicness is handled. In
principle the caller can supply fewer arguments for some request kinds,
although the manpage discourages that practice. musl could accept such calls
like this:

	pid = 0; addr = data = 0;
	if (req != PTRACE_TRACEME) {
		va_start(ap, req);
		pid = va_arg(ap, pid_t);
		if (req != PTRACE_KILL && /*other 2-arg reqs*/) {
			addr = va_arg(ap, void *);
			if (req != PTRACE_PEEKDATA && /*other 3-arg reqs*/)
				data = va_arg(ap, void *);
		}
		va_end(ap);
	}

Thanks.
Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.