1. 14 1月, 2015 2 次提交
  2. 19 3月, 2014 7 次提交
  3. 18 1月, 2012 1 次提交
    • N
      Kernel: Audit Support For The ARM Platform · 29ef73b7
      Nathaniel Husted 提交于
      This patch provides functionality to audit system call events on the
      ARM platform. The implementation was based off the structure of the
      MIPS platform and information in this
      (http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html)
      mailing list thread. The required audit_syscall_exit and
      audit_syscall_entry checks were added to ptrace using the standard
      registers for system call values (r0 through r3). A thread information
      flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
      added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
      entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
      set, the syscall_trace function will be executed. The prober changes
      were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.
      
      Due to platform availability limitations, this patch was only tested
      on the Android platform running the modified "android-goldfish-2.6.29"
      kernel. A test compile was performed using Code Sourcery's
      cross-compilation toolset and the current linux-3.0 stable kernel. The
      changes compile without error. I'm hoping, due to the simple modifications,
      the patch is "obviously correct".
      Signed-off-by: NNathaniel Husted <nhusted@gmail.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      29ef73b7
  4. 14 7月, 2011 3 次提交
    • J
      ARM: kprobes: Extend arch_specific_insn to add pointer to emulated instruction · e2960317
      Jon Medhurst 提交于
      When we come to emulating Thumb instructions then, to interwork
      correctly, the code on in the instruction slot must be invoked with a
      function pointer which has the least significant bit set. Rather that
      set this by hand in every Thumb emulation function we will add a new
      field for this purpose to arch_specific_insn, called insn_fn.
      
      This also enables us to seamlessly share emulation functions between ARM
      and Thumb code.
      Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      e2960317
    • J
      ARM: kprobes: Add hooks to override singlestep() · c6a7d97d
      Jon Medhurst 提交于
      When a probe fires we must single-step the instruction which was
      replaced by a breakpoint. As the steps to do this vary between ARM and
      Thumb instructions we need a way to customise single-stepping.
      
      This is done by adding a new hook called insn_singlestep to
      arch_specific_insn which is initialised by the instruction decoding
      functions.
      
      These single-step hooks must update PC and call the instruction handler.
      For Thumb instructions an additional step of updating ITSTATE is needed.
      We do this after calling the handler because some handlers will need to
      test if they are running in an IT block.
      Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      c6a7d97d
    • J
      ARM: kprobes: Split out internal parts of kprobes.h · 221bf15f
      Jon Medhurst 提交于
      Later, we will be adding a considerable amount of internal
      implementation definitions to kprobe header files and it would be good
      to have these in local header file along side the source code, rather
      than pollute the existing header which is include by all users of
      kprobes.
      
      To this end, we add arch/arm/kernel/kprobes.h and move into this the
      existing internal defintions from arch/arm/include/asm/kprobes.h
      Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      221bf15f
  5. 29 4月, 2011 1 次提交
  6. 01 9月, 2008 1 次提交
  7. 03 8月, 2008 1 次提交
  8. 02 6月, 2008 1 次提交
  9. 05 3月, 2008 1 次提交
  10. 26 1月, 2008 3 次提交
    • N
      ARM kprobes: special hook for the kprobes breakpoint handler · 79696910
      Nicolas Pitre 提交于
      The kprobes code is already able to cope with reentrant probes, so its
      handler must be called outside of the region protected by undef_lock.
      
      If ever this lock is released when handlers are called then this commit
      could be reverted.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      79696910
    • A
      ARM kprobes: core code · 24ba613c
      Abhishek Sagar 提交于
      This is a full implementation of Kprobes including Jprobes and
      Kretprobes support.
      
      This ARM implementation does not follow the usual kprobes double-
      exception model. The traditional model is where the initial kprobes
      breakpoint calls kprobe_handler(), which returns from exception to
      execute the instruction in its original context, then immediately
      re-enters after a second breakpoint (or single-stepping exception)
      into post_kprobe_handler(), each time the probe is hit..  The ARM
      implementation only executes one kprobes exception per hit, so no
      post_kprobe_handler() phase. All side-effects from the kprobe'd
      instruction are resolved before returning from the initial exception.
      As a result, all instructions are _always_ effectively boosted
      regardless of the type of instruction, and even regardless of whether
      or not there is a post-handler for the probe.
      Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      24ba613c
    • Q
      ARM kprobes: instruction single-stepping support · 35aa1df4
      Quentin Barnes 提交于
      This is the code implementing instruction single-stepping for kprobes
      on ARM.
      
      To get around the limitation of no Next-PC and no hardware single-
      stepping, all kprobe'd instructions are split into three camps:
      simulation, emulation, and rejected. "Simulated" instructions are
      those instructions which behavior is reproduced by straight C code.
      "Emulated" instructions are ones that are copied, slightly altered
      and executed directly in the instruction slot to reproduce their
      behavior.  "Rejected" instructions are ones that could be simulated,
      but work hasn't been put into simulating them. These instructions
      should be very rare, if not unencountered, in the kernel. If ever
      needed, code could be added to simulate them.
      
      One might wonder why this and the ptrace singlestep facility are not
      sharing some code.  Both approaches are fundamentally different because
      the ptrace code regains control after the stepped instruction by installing
      a breakpoint after the instruction itself, and possibly at the location
      where the instruction might be branching to, instead of simulating or
      emulating the target instruction.
      
      The ptrace approach isn't suitable for kprobes because the breakpoints
      would have to be moved back, and the icache flushed, everytime the
      probe is hit to let normal code execution resume, which would have a
      significant performance impact. It is also racy on SMP since another
      CPU could, with the right timing, sail through the probe point without
      being caught.  Because ptrace single-stepping always result in a
      different process to be scheduled, the concern for performance is much
      less significant.
      
      On the other hand, the kprobes approach isn't (currently) suitable for
      ptrace because it has no provision for proper user space memory
      protection and translation, and even if that was implemented, the gain
      wouldn't be worth the added complexity in the ptrace path compared to
      the current approach.
      
      So, until kprobes does support user space, both kprobes and ptrace are
      best kept independent and separate.
      Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      35aa1df4