Re: disabling group leader perf_event

[Alan Cox]

> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/