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]

Message-ID: <20151109144309.361ab4e5@gandalf.local.home>
Date:	Mon, 9 Nov 2015 14:43:09 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	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, 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.

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.

-- Steve

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