[PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist
panand at redhat.com
Thu Mar 17 00:57:26 PDT 2016
On 16/03/2016:10:27:22 AM, James Morse wrote:
> Hi Pratyush,
> On 16/03/16 05:43, Pratyush Anand wrote:
> > On 15/03/2016:06:47:52 PM, James Morse wrote:
> >> If I understand this correctly - you can't kprobe these ldr/str instructions
> >> as the fault handler wouldn't find kprobe's out-of line version of the
> >> instruction in the exception table... but why only these two functions? (for
> >> library functions, we also have clear_user() and copy_in_user()...)
> > May be not clear_user() because those are inlined, but may be __clear_user().
> You're right - the other library functions in that same directory is what I meant..
> >> Is it feasible to search the exception table at runtime instead? If an
> >> address-to-be-kprobed appears in the list, we know it could generate exceptions,
> >> so we should report that we can't probe this address. That would catch all of
> >> the library functions, all the places uaccess.h was inlined, and anything new
> >> that gets invented in the future.
> > Sorry, probably I could not get it. How can an inlined addresses range be placed
> > in exception table or any other code area.
> Ah, not a section or code area, sorry I wasn't clear:
> When a fault happens in the kernel, the fault handler
> (/arch/arm64/mm/fault.c:do_page_fault()) calls search_exception_tables(regs->pc)
> to see if the faulting address has a 'fixup' registered. If it does, the fixup
> causes -EFAULT to be returned, if not it ends up in die().
> The horrible block of assembler in
> arch/arm64/include/asm/uaccess.h:__get_user_asm() adds the address of the
> instruction that is allowed to fault to the __ex_table section:
> > .section __ex_table,"a"
> > .align 3
> > .quad 1b, 3b
> > .previous
> Here 1b is the address of the instruction that can fault, and 3b is the fixup
> that moves -EFAULT into the return value.
> This works for get_user() and friends which are inlined all over the kernel. It
> even works for modules, as there is an exception table for each module which is
> searched by kernel/module.c:search_module_extables().
> This list of addresses that can fault already exists, there is even an API
> function to check for a given address. Grabbing the nearest vmlinux, there are
> ~1300 entries in the __ex_table section, this patch blacklists two of them,
> using search_exception_tables() obviously blacklists them all.
Thanks a lot for explaining it. Got it now. So agreeing to your idea. But....
> I've had a quick look at x86 and sparc, it looks like they allowed probed
> instructions to fault, do_page_fault()->kprobes_fault()->kprobe_fault_handler()
> - which uses the original probed address with search_exception_tables() to find
> and run the fixup. I doubt this is needed in an initial version of kprobes,
> (maybe its later in this series - I haven't read all the way through it yet).
Hummmm..We do have fixup_exception() in arm64 kprobe_fault_handler(). So, it
should have worked, without this patch.
@David: This patch was added in v9 and fixup_exception() had been dropped in v9.
Since, dropping of fixup_exception() also caused to fail some systemtap test
cases, so it was added back in v10. I wonder if we really need this patch.
May be you can try to run related test case by dropping this patch.
Thanks James for bringing this out.
More information about the linux-arm-kernel