Message-ID: <1283875344.5133.123.camel@gandalf.stny.rr.com>
Date:	Tue, 07 Sep 2010 12:02:24 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
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>,
	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 Tue, 2010-09-07 at 16:47 +0300, Avi Kivity wrote:

> > 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)
> 
> We can't allow untrusted access to random kernel memory.
> 
> Let's take netfilter as an example.  Userspace downloads bytecode to 
> determine whether to allow a packet or not, or to mangle it.  The kernel 
> exposes APIs to read and write the packet, access the conntrack hash, 
> and whatever else is needed.  The bytecode reads the packet, allows, 
> denies or mangles to taste, and exits.
> 
> > 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.
> 
> I don't understand this example.  Why would you need such bytecode?

I was just using this as if we were to use this bytecode for filtering
on parameters and we wanted to look at the same stuff that goes into the
buffers, but before we touch the buffer code.

> 
> For untrusted filters, you only allow access to tracepoint arguments.  
> For trusted filters, perhaps, you can allow arbitrary memory access at 
> the user's own risk.

I was thinking this too.

> 
> > 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.
> 
> The way I see it, we expose a function pointer vector to the untrusted 
> code, similar to the syscall vector.  Trusted code may also see 
> functions to access kernel memory (or we just loosen up the validation 
> rules).

Ah, kind of what the tracepoints already do. Taking the same example:

        TP_fast_assign(
                __entry->hva            = hva;
                __entry->gfn            =
                  slot->base_gfn + ((hva - slot->userspace_addr) >> PAGE_SHIFT);
                __entry->referenced     = ref;
        ),

Have a function does the slot->base_gfn... work for us. It would also be
required that the only input is indeed the slot pointer, otherwise you
could dereference any tracepoint argument. So the arguments to the
tracepoint may get a list of helper functions that allow filtering on
dereferences to them.

This is getting a bit over-engineered IMO. If we want to do something
with the tracepoints, it should start out with simply taking the
arguments that are passed in, and then manipulating them and testing
them. Perhaps we allow a single page of heap to let the algorithms work
with.

Later, we could add functionality that could be triggered with a
condition. The first thing that comes to mind is a way to trigger the
start of tracing or stopping a trace.

-- Steve


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

Powered by blists - more mailing lists