linux-kernel - Re: [PATCH 00/12] tracing: add compat syscall support v2

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

Date:	Fri, 12 Mar 2010 04:27:17 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Jason Baron <jbaron@...hat.com>
Cc:	mingo@...e.hu, rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	laijs@...fujitsu.com, lizf@...fujitsu.com, hpa@...or.com,
	tglx@...utronix.de, mhiramat@...hat.com, heiko.carstens@...ibm.com,
	benh@...nel.crashing.org, davem@...emloft.net, lethal@...ux-sh.org,
	schwidefsky@...ibm.com, brueckner@...ux.vnet.ibm.com,
	tony.luck@...el.com
Subject: Re: [PATCH 00/12] tracing: add compat syscall support v2

On Thu, Mar 11, 2010 at 05:12:28PM -0500, Jason Baron wrote:
> I kept separate namespaces to avoid collisions and generally simplify
> things. However, you are right - we can maintain namespace separation at the
> "sys32_blah", "compat_sys", level and map to a common "compat_blah" for the
> trace event name. We can avoid collisions by simply storing the "sys32" or
> "compat_sys" name in the syscall metadata structure name field. 


Well, the purpose is also to reach a state near to cross arch generic
for tools.

If we have a script that parses compat syscalls events in arch X, it
would be nice if it works on arch Y.

If arch X overrides compat_blah through sys32_blah and arch Y just keep
compat_blah, the script won't cross work.

The problem is not that trivial to solve though, I guess the best is to
remove the compat_blah trace event if we already have sys32_blah.
Also the syscall handler naming doesn't seem to be always unified (not
talking about the sys32 thing but the name of the syscall itself).

So let's start simple for now, we can just include everything and
solve that incrementally. But a good start would be to have a separate
compat_syscalls event subsystem.

 
> > - We probably want a compat_syscalls trace event subsystem (separated
> > from syscalls), can be done incrementally though
> > 
> > - Commit e7b8e675d9c71b868b66f62f725a948047514719
> >   (tracing: Unify arch_syscall_addr() implementations)
> > has made a good use of the unified syscall table name
> > between archs that support syscall tracing so that we
> > can, most of the time, directly dereference it from generic
> > code. Exotic archs can still override arch_syscall_addr()
> > if we can't do that with their syscall table.
> > I wish we can do that with the compat syscall tables too.
> > Compat syscall tables names seem to be less unified for now
> > though. Again, can be done incrementally.
> > 
> > Other than that, that's a cool batch!
> > 
> > Thanks!
> > 
> 
> the other question is how to go about getting arch support, since right
> now we break non-x86 arches which have CONFIG_FTRACE_SYSCALLS and
> CONFIG_COMPAT set with this patch.


I guess we can handle that with an ARCH_HAVE_FTRACE_COMPAT_SYSCALLS.
It's not that broken actually, compat syscalls events will just
not trigger.



> thanks,
> 
> -Jason

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