Re: disabling group leader perf_event

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2010-09-06 at 17:47 +0200, Ingo Molnar wrote:

> > The actual language doesn't really matter.
> 
> There are 3 basic categories:
> 
>  1- Most (least abstract) specific code: a block of bytecode in the form 
>     of a simplified, executable, kernel-checked x86 machine code block - 
>     this is also the fastest form. [yes, this is actually possible.]
> 
>  2- Least specific (most abstract) code: A subset/sideset of C - as it's 
>     the most kernel-developer-trustable/debuggable form.
> 
>  3- Everything else little more than a dot on the spectrum between the
>     first two points.
> 
> I lean towards #2 - but #1 looks interesting too. #3 is distinctly 
> uninteresting as it cannot be as fast as #1 and cannot be as convenient 
> as #2.

I would lean to passing a limited assembly language to the kernel, in
ASCII. This would do the following:

1) probably the easiest to verify.

2) we could write a simple interpreter that all archs can use

3) each arch can have a simple compiler to convert the assembly to
native byte code to optimize it.


The input, output and memory heap can be expressed and the kernel can
grant or deny any of what is touched.

Now here's some of my concerns for any of this. Using the kvm tracepoint
as an example:

slot->base_gfn + ((hva - slot->userspace_addr) >> PAGE_SHIFT)


If we were given "slot" and now we need to dereference it to get
base_gfn or userspace_addr, how would the kernel know this is a valid
address that can be read? Seems to me that this may allow userspace to
trivially see parts of the kernel that was never meant to be seen.

One reason that ftrace only allows root access, is that the kernel is
best a black box for most userspace.  Letting userspace see how SELinux
is treating it, and finding addresses that SELinux is using, can give a
large arsenal to black hats that are writing tools to circumvent Linux
security.

Unless we only let this interpreter access the inputs and its own
allocated memory, it will be very difficult to verify what the
interpreter is doing. I guess one thing we could do is to have a table
of places in the kernel that we let userspace see. This table will need
strict scrutinizing to verify that it can't be used to exploit other
parts of the kernel.

-- Steve