[lkml]   [2011]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/4] MIPS Kprobes: Deny probes on ll/sc instructions
    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.


    > Ralf

     \ /
      Last update: 2011-11-16 18:41    [W:0.035 / U:62.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site