lkml.org 
[lkml]   [2010]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disabling group leader perf_event

* Pekka Enberg <penberg@kernel.org> wrote:

> 2010/9/8 Paul Mackerras <paulus@samba.org>:
> >> We start with trivial (and useless) special case of something like:
> >>
> >> #define MAX_BYTECODE_SIZE 256
> >>
> >> int x86_bytecode_verify(char *opcodes, unsigned int len)
> >> {
> >>
> >>       if (len-1 > MAX_BYTECODE_SIZE-1)
> >>               return -EINVAL;
> >>
> >>       if (opcodes[0] != 0xc3) /* RET instruction */
> >>               return -EINVAL;
> >>
> >>       return 0;
> >> }
> >>
> >> ... and then we add checks for accepted/safe x86 patterns of
> >> instructions step by step - always keeping it 100% correct.
> >
> > So... I would be interested to see you add the case for the MOV
> > instruction. :)
>
> Heh, which one of them - there are tons of variants under 'mov' on
> x86? On a more serious note: the biggest problem is that you need to
> do verification during execution because you don't know the exact
> address until then for most addressing modes that use registers.

Well, the main model and usecase would be to provide some sort of
function (in the mathematical sense), which is dependent on fixed-size
input and stores a fixed-size output somewhere.

For that category to restrict both the input and output space initially,
wouldnt be a big restriction. I.e. dont allow register addresses, only
stack addresses or fixed addresses to the user-space parameter space.

These functions are supposed to be short and generally they dont change
state (they dont have access to locking in any case - we want to be able
to call them from atomic contexts, etc.).

Thus instructions like 'mov (%rax), ...' would be handled by not
allowing them, only addresses which do not change from execution state.

That still gives plenty of flexibility to implement filters or other
kinds of input/output calculation/netfilter-rule kind of logic.

Do you know some interesting usecase that would be excluded via such
address restrictions? Things like flexible arrays or more complex data
structures such as trees couldnt be used initially. More complex data
structures would need locking in any case.

I.e. it would initially be restricted roughly to code where halting can
be proven. Still looks interesting to me: most netfilter policy rules,
trace filters or selinux rules could be implemented that way - an order
of magnitude or two faster than the ad-hoc tracing, avc or iptables rule
engines ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-09-08 08:47    [from the cache]
©2003-2011 Jasper Spaans