linux-kernel - Re: linux-next: add utrace tree

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: <alpine.LFD.2.00.1001241731270.2906@localhost.localdomain>
Date:	Sun, 24 Jan 2010 17:36:21 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Frank Ch. Eigler" <fche@...hat.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Tom Zanussi <tzanussi@...il.com>, systemtap@...rces.redhat.com,
	dle-develop@...ts.sourceforge.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com
Subject: Re: linux-next: add utrace tree

On Sat, 23 Jan 2010, Frank Ch. Eigler wrote:
> On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote:
> 
> > [...]  Also, if any systemtap person is interested in helping us
> > create a more generic filter engine out of the current ftrace filter
> > engine (which is really a precursor of a safe, sandboxed in-kernel
> > script engine), that would be excellent as well. [...]
> 
> Thank you for the invitation.
> 
> > More could be done - a simple C-like set of function perhaps - some minimal 
> > per probe local variable state, etc. (perhaps even looping as well, with a 
> > limit on number of predicament executions per filter invocation.)
> 
> Yes, at some point when such bytecode intepreter gets rich enough, one
> may not need the translated-to-C means of running scripts.
> 
> 
> > ( _Such_ a facility, could then perhaps be used to allow applications access 
> >   to safe syscall sandboxing techniques: i.e. a programmable seccomp concept 
> >   in essence, controlled via ASCII space filter expressions [...]
> >   IMHO that would be a superior concept for security modules too [...]
> >
> > [...]  specific functionality with an immediately visible upside,
> > with no need for opaque hooks.
> 
> This OTOH seem like rather a stretch.  If one claims that "opaque
> hooks" are bad, so instead have hooks that jump not to auditable C
> code but an bytecode interpreter?  And have the bytecodes be uploaded
> from userspace?  How is this supposed to produce "transparency" from
> the kernel/hook point of view?

Simply because the kernel controls which byte code is executed and has
control over the functionality behind it. That makes the hooks well
defined and transparent.

Thanks,

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