linux-kernel - Re: disabling group leader perf

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: <4C8506B5.1040808@redhat.com>
Date:	Mon, 06 Sep 2010 18:20:21 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...helsinki.fi>,
	Tom Zanussi <tzanussi@...il.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-perf-users@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: disabling group leader perf_event

  On 09/06/2010 06:30 PM, Alan Cox wrote:
>
>> For me the requirements are:
>> - turing complete (more than just filters)
> Needs infinite storage and may not terminate

Ow come on.  We can always terminate it by inserting checks and 
unwinding the stack; and obviously we'll limit storage.

>> - easy interface to kernel APIs (like hrtimers)
>> - safe to use by untrusted users
>>
>> The actual language doesn't really matter.
> It does for performance and audit. You don't want a JIT as it murders
> cache performance,

Strangely, everyone uses a jit these days unless they're memory 
constrained.  Yes it costs cache, but an interpreter is still slower.

> which means you want
>
> - no self modification

Right.

> - bounded run time

No, I want the ability to terminate the code at any time and clean up 
any resources used.  We have exactly the same requirements for ordinary 
userspace.

> - bounded memory use
> - trustable behaviour for access

Right.

> and usually minimal side effects since you want to optimise very
> heavily and side effects stop that (which is also why Fortran still kicks
> C's backside for crunching)
>
> Not sure you need/want to do the conversion in kernel.

I prefer bytecode as well.

> I'd have thought a
> sane way to handle it would have been to throw stuff at the kernel in
> some kind of semi-sane byte code that can be interpreted by a noddy
> interpreter but firstly when you get it have the kernel try and run a
> helper to compile it.

So you do want to jit?

-- 
error compiling committee.c: too many arguments to function

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