Re: disabling group leader perf_event

[Ingo Molnar <mingo@elte.hu>]

* 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