linux-kernel - Re: Compat syscall instrumentation and return from execve issue

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:	Mon, 9 Nov 2015 12:57:06 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andy Lutomirski <luto@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Anvin, H. Peter" <hpa@...or.com>,
	lttng-dev <lttng-dev@...ts.lttng.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Compat syscall instrumentation and return from execve issue

On Mon, Nov 9, 2015 at 11:43 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 9 Nov 2015 11:29:10 -0800
> Andy Lutomirski <luto@...nel.org> wrote:
>
>> > I'm thinking the TS_EXECVE flag would be the least intrusive. Add a
>> > comment that it is used by tracepoints to map between compat and
>> > non-compat syscalls when execve switches the flag. This would not need
>> > to touch any of the logic of the hotpaths within the systemcalls
>> > themselves.
>>
>> Let's make it really simple: add an 'unsigned int arch' to
>> syscall_return_slowpath.  As of last week, Linus' tree sends all compat
>> returns, without exception (except brand new children, depending on your
>> point of view), through that path, and the caller always knows the
>> architecture.
>>
>> But keep in mind that any games you play here are going to get
>> completely and utterly screwed up if anyone is playing with ptrace to
>> change syscall numbers.  You'd also going to have problems with syscall
>> restart, sigreturn, etc, so it would be nice to have an argument that
>> the putative solution solves the problem for real instead of just adding
>> complexity to paper it over.
>>
>> Meanwhile, I'm trying to remove all of the magic from the handling of
>> execve, and I'm half-way there.  Let's please not add more, especially
>> if that magic needs to touch asm code.
>
> The solution I suggested wouldn't touch any asm code. The only change
> would be to reserve the TS_EXECVE flag. Actually, come to think of it,
> we could have Mathieu's TS_ORIG_COMPAT flag, and still only have the
> tracepoint syscall set it, such that the matching tracepoint syscall
> exit would know that the initial call was COMPAT or not.

Someone needs to clear TS_EXECVE, though.

>
> The goal is only to make sure that the system call exit tracepoint
> matches the system call enter tracepoint.
>
> The system call enter would set or clear the TS_ORIG_COMPAT if the
> TS_COMPAT is set when entering the system call, and it would check that
> flag when exiting the system call.

This seems a bit odd, though, since we aren't very good about
preserving the syscall nr or the args through syscall processing.  In
any event, in the new improved x86 syscall code, we know what arch we
are just by following the control flow, so no flags should be needed.
Hence my suggestion of just adding an "unsigned int arch" to the
return slowpath.

--Andy
--
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/