From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: rostedt <rostedt@goodmis.org>, Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
lttng-dev <lttng-dev@lists.lttng.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Compat syscall instrumentation and return from execve issue
Date: Wed, 18 Nov 2015 14:57:17 +0000 (UTC) [thread overview]
Message-ID: <1455473985.114184.1447858637821.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CALCETrVL2BqDEcmFpQ_jDp6C35qEMg1V2sVMHhuE3D9LA2Z1jg@mail.gmail.com>
----- On Nov 11, 2015, at 8:08 PM, Andy Lutomirski luto@amacapital.net wrote:
> On Mon, Nov 9, 2015 at 6:31 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Mon, 9 Nov 2015 17:51:25 -0800
>> Andy Lutomirski <luto@amacapital.net> wrote:
>>
>>
>>> 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).
>>>
>>
>> OK, so you are saying that a execve that switches the current state
>> into ia32 will return from the do_syscall_64 regardless? Then we would
>> have to add tracepoints that would be for both ia32 and x86_64. But
>> that would solve the current issue at hand.
>>
>
> Indeed. Unlike fork/clone, execve is only magical insofar as it does
> magical things to task_struct and it enters in the 64-bit native case
> through a nasty asm path. The former has no effect on the entry code
> (except most likely blocking opportunistic sysret because we're a bit
> silly and it might break ABI to change that), and the latter barely
> matters for this purpose. In any event, I'm planning on getting rid
> of the asm stub for 4.5 if I can get the code written and tested in
> time.
I guess there are no plans to do this kind of change to other
architectures in the near future ? If so, we might want to
investigate the thread status flag approach for other architectures,
and use the AUDIT_ARCH_* approach for x86.
Thoughts ?
Thanks,
Mathieu
>
> --Andy
>
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
prev parent reply other threads:[~2015-11-18 14:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-08 19:37 Compat syscall instrumentation and return from execve issue Mathieu Desnoyers
2015-11-09 16:05 ` Steven Rostedt
2015-11-09 19:29 ` Andy Lutomirski
2015-11-09 19:43 ` Steven Rostedt
2015-11-09 20:57 ` Andy Lutomirski
2015-11-09 21:12 ` Steven Rostedt
2015-11-10 1:39 ` Mathieu Desnoyers
2015-11-10 1:51 ` Andy Lutomirski
2015-11-10 2:31 ` Steven Rostedt
2015-11-12 1:08 ` Andy Lutomirski
2015-11-18 14:57 ` Mathieu Desnoyers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1455473985.114184.1447858637821.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lttng-dev@lists.lttng.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.