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: <CALCETrWstqEStWLFLvtridbc7CFzfv98QgZ44AiJpkU84yvVNw@mail.gmail.com>
Date:	Mon, 9 Nov 2015 17:51:25 -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 1:12 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 9 Nov 2015 12:57:06 -0800
> Andy Lutomirski <luto@...capital.net> wrote:
>
>> > 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.
>
> Well, it gets set and cleared by the syscall enter (same for
> TS_ORIG_COMPAT), and exit for that matter.
>
> It's trivial to have a tracepoint hook added when either system call
> enter or exit tracepoints are enabled. Thus, the setting and clearing of
> the flag can be done by another callback at those tracepoints.
>
>>
>> >
>> > 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.
>
> I guess I don't understand this "unsigned int arch".
>
> When the execve system call is called, it's running in x86_64 mode, and
> then the execve changes the state to ia32 bit mode. Then on return, the
> tracepoint system call exit, has the x86_64 system call number, but if
> it checks to see what state the task is in, it will see ia32 state, and
> then report the number for ia32 instead.
>
> For example, in x86_64, execve is 59, and that number is passed to the
> system call enter tracepoint. Now on return of the system call, the
> system call exit tracepoint gets called with 59 as the system call as
> well, but if that tracepoint checks the state, it will think its
> returning the "olduname" system call (that's 59 for ia32).
>
> What change are you making to solve this?
>

do_syscall_32_irqs_on would call syscall_return_slowpath(regs,
AUDIT_ARCH_I386).  do_syscall_64 (which doesn't exist yet) would call
syscall_return_slowpath(regs, AUDIT_ARCH_X86_64).

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