linux-kernel - Re: [RFC/PATCH] Implement new PTRACE_EVENT_SYSCALL

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu,  9 Jan 2014 13:04:56 -0800 (PST)
From:	Roland McGrath <roland@...k.frob.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Sergio Durigan Junior <sergiodj@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Pedro Alves <palves@...hat.com>,
	Tom Tromey <tromey@...hat.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}

> I won't argue, but it is not clear to me if this is really useful,
> given that the debugger can read the regs.

I do see the utility of having a consistent machine-independent way to get
the syscall number from userspace.  But note that this could be probably
accomplished with just a uapi header change, providing an inline or macro
to extract the syscall number from the regset data.  (It was once the case
that there were some machines where the syscall number is not in any
register and has to be extracted by decoding the instruction.  I'm not sure
if that is still an issue anywhere.)

Also note that adding a separate copy of the syscall number introduces a
new wrinkle into the interface.  This might be considered to be good, bad,
or indifferent, but I think it should at least be considered explicitly.
That is, at the entry stop the syscall number (when it's in a register) can
be changed via ptrace.  So if the number is delivered via ptrace_message,
that's a separate copy of the original number that does not reflect any
changes made via ptrace--so it reflects what userland asked for, as opposed
to what the kernel actually acted on.

I don't have a particular opinion about which way to go with that.
I just wanted all the issues (I'm aware of) to be considered.

I absolutely concur that all new tracing features should work in the
existing style of PTRACE_EVENT_* that a PTRACE_O_* flag enables it and
then it applies for all kinds of running under ptrace.  Things like
PTRACE_SYSCALL that combine what-to-report with how-to-run are terrible
and should never be done again.

Thanks,
Roland
--
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/