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.