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]

Date:	Mon, 6 Sep 2010 16:30:41 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Avi Kivity <avi@...hat.com>
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

> > This could be used for far more than just instrumentation: IMO security
> > policies could be expressed in such a way. (Simplified, they are quite
> > similar to filters installed on syscall entry/exit, with the ability of
> > the filter to influence whether the syscall is performed.)

Hardly - security policy is almost entirely based on context and state
change, the syscalls causing the state change are usually of minor
interest

(eg we don't care how the uid or chmod bits got set, we care what value
they hold)

> For me the requirements are:
> - turing complete (more than just filters)

Needs infinite storage and may not terminate

> - 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, which means you want

- no self modification
- bounded run time
- bounded memory use
- trustable behaviour for access

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'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.

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