Hi Ralf, Please see inline On Wed, 16 Nov 2011, Ralf Baechle wrote: > On Tue, Nov 08, 2011 at 03:26:42PM -0800, Victor Kamensky wrote: > > > > s/insturctions/instructions/ > > > > > > Not only is it a bad idea, it will probably make them fail 100% of the time. > > > > > > It is also an equally bad idea to place a probe between any LL and SC > > > instructions. How do you prevent that? > > > > As per below code comment we don't prevent that. There is no way to do > > that. > > Similar to the way that the addresses of loads and stores from userspace > are recorded in a special section we could build a list of forbidden > address range. > > Is it worth it? Yes, probably it could be done this way. It would require to change all places where ll/sc used. Infrastructure to look at those tables in kernel and in all loaded modules will be required. Cost of check in kprobes layer will go up as well, but probably on acceptable level. In my personal opinion benefits it would bring will not worth the effort. Couple more, hopefully relevant, notes: - on kprobes CPU independent layer there is already __kprobes marker (attribute section) that could be used to mark function where kprobes insertion is not allowed. So one may use it, albeit on function level granularity, not code range. - in my personal opinion all these checks have just practical meaning and practical limitations. For example current mips kprobes check whether instruction is in delay slot looks at previous 4 bytes to match jump or branch instruction pattern. It works and really helps in 99.99% of the cases but it will break in some exotic case where the instruction follows data (jump table for example) or padding that happens to match jump or branch instruction pattern. Or even if instruction follows jump and branch instruction, it could be jumped directly on it (i.e serve as branch delay slot in one case and regular instruction in another case). In all such obscure cases current delay slot instruction check would produce false positive. And it is perfectly fine, given practical consideration. I just bring this to illustrate my point that in this sort of situations, where we are trying to prevent API caller to shot himself/herself in the foot, we don't need to push to absolute solutions, just practical one. Thanks, Victor > Ralf >
