Messages in this thread | | | Date | Wed, 8 Sep 2010 08:44:27 +0200 | From | Ingo Molnar <> | Subject | Re: 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/
| |