linux-kernel - Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler

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: <4F73CC3A.2080901@zytor.com>
Date:	Wed, 28 Mar 2012 19:43:06 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vaibhav Nagarnaik <vnagarnaik@...gle.com>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	David Sharp <dhsharp@...gle.com>,
	Justin Teravest <teravest@...gle.com>,
	Laurent Chavey <chavey@...gle.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace
 handler

On 03/28/2012 11:23 AM, Vaibhav Nagarnaik wrote:
> 
> I am sorry I don't see how that would be possible without having some
> sort of architecture dependent changes.

Tough, that's sometimes the way it goes.  On most architectures it's
just a simple table.

> Also as you mentioned, it will have some security considerations.

Not any more than your little scheme.

> If you can suggest a better way without going through this macro
> magic, I will be glad to implement it. The 2 main reasons I made this
> patch was to remove the added latency in syscall tracing and to remove
> penalty for syscalls that are not traced.

But instead you add a penalty for every syscall, even if tracing is
disabled.  Not cool.

> If you can suggest a better way without going through this macro
> magic, I will be glad to implement it.

The more I look at this stuff the more I think it is not just crazy, but
batsh*t crazy... we produce *how* much "metadata" which is stored in
non-pageable kernel memory, and all it seems to be *actually* doing is
store a variable number of parameters in a buffer.

This is insane.  Not just a little insane, but utterly bonkers.

The syscall interface is the single most stable interface in the kernel.
 Just plunk down the system call number and the six arguments in the
buffer, and be done with it.  On the way out, there is a single return
argument, *by design*.  No need to burden the kernel in this way! That
this information can be perfectly well decoded in userspace is already
shown by strace, although it would be highly beneficial if the kernel
build could export information to strace and other tools.  There is
absolutely no need for it to live in kernel memory, though.

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