From: James Morse <james.morse@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: "David Long" <dave.long@linaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will.deacon@arm.com>,
"Sandeepa Prabhu" <sandeepa.s.prabhu@gmail.com>,
"William Cohen" <wcohen@redhat.com>,
"Steve Capper" <steve.capper@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Marc Zyngier" <marc.zyngier@arm.com>,
"Dave P Martin" <Dave.Martin@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Robin Murphy" <Robin.Murphy@arm.com>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Jens Wiklander" <jens.wiklander@linaro.org>,
"Christoffer Dall" <christoffer.dall@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Yang Shi" <yang.shi@linaro.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Suzuki K. Poulose" <suzuki.poulose@arm.com>,
"Kees Cook" <keescook@chromium.org>,
"Zi Shen Lim" <zlim.lnx@gmail.com>,
"John Blackwood" <john.blackwood@ccur.com>,
"Feng Kan" <fkan@apm.com>,
"Balamurugan Shanmugam" <bshanmugam@apm.com>,
"Vladimir Murzin" <Vladimir.Murzin@arm.com>,
"Mark Salyzyn" <salyzyn@android.com>,
"Petr Mladek" <pmladek@suse.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist
Date: Wed, 16 Mar 2016 10:27:22 +0000 [thread overview]
Message-ID: <56E9350A.7010909@arm.com> (raw)
In-Reply-To: <20160316054329.GC28915@dhcppc6.redhat.com>
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.
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).
Thanks,
James
next prev parent reply other threads:[~2016-03-16 10:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 5:32 [PATCH v11 0/9] arm64: Add kernel probes (kprobes) support David Long
2016-03-09 5:32 ` [PATCH v11 1/9] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2016-03-11 18:07 ` James Morse
2016-03-18 13:06 ` David Long
2016-03-15 11:04 ` Marc Zyngier
2016-03-21 7:08 ` David Long
2016-03-09 5:32 ` [PATCH v11 2/9] arm64: Add more test functions to insn.c David Long
2016-03-09 5:32 ` [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist David Long
2016-03-15 18:47 ` James Morse
2016-03-16 5:43 ` Pratyush Anand
2016-03-16 10:27 ` James Morse [this message]
2016-03-17 7:57 ` Pratyush Anand
2016-03-18 13:29 ` Pratyush Anand
2016-03-18 14:02 ` James Morse
2016-03-18 14:43 ` Pratyush Anand
2016-03-18 18:12 ` James Morse
2016-03-21 5:17 ` Pratyush Anand
2016-03-21 14:52 ` Will Deacon
2016-03-22 16:51 ` Pratyush Anand
2016-03-17 12:04 ` 平松雅巳 / HIRAMATU,MASAMI
2016-03-09 5:32 ` [PATCH v11 4/9] arm64: add conditional instruction simulation support David Long
2016-03-13 12:09 ` Marc Zyngier
2016-03-14 4:04 ` Pratyush Anand
2016-03-14 7:38 ` Marc Zyngier
2016-03-21 8:35 ` David Long
2016-03-09 5:32 ` [PATCH v11 5/9] arm64: Kprobes with single stepping support David Long
2016-04-20 1:29 ` Li Bin
2016-03-09 5:32 ` [PATCH v11 6/9] arm64: kprobes instruction simulation support David Long
2016-03-12 3:56 ` Marc Zyngier
2016-03-21 9:39 ` David Long
2016-03-09 5:32 ` [PATCH v11 7/9] arm64: Add trampoline code for kretprobes David Long
2016-03-13 13:52 ` Marc Zyngier
2016-03-21 13:30 ` David Long
2016-03-09 5:32 ` [PATCH v11 8/9] arm64: Add kernel return probes support (kretprobes) David Long
2016-03-17 12:22 ` 平松雅巳 / HIRAMATU,MASAMI
2016-03-17 12:58 ` 平松雅巳 / HIRAMATU,MASAMI
2016-03-21 13:33 ` David Long
2016-03-09 5:32 ` [PATCH v11 9/9] kprobes: Add arm64 case in kprobe example module David Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E9350A.7010909@arm.com \
--to=james.morse@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Robin.Murphy@arm.com \
--cc=Vladimir.Murzin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex.bennee@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=broonie@kernel.org \
--cc=bshanmugam@apm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=dave.long@linaro.org \
--cc=fkan@apm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jens.wiklander@linaro.org \
--cc=john.blackwood@ccur.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=panand@redhat.com \
--cc=pmladek@suse.com \
--cc=salyzyn@android.com \
--cc=sandeepa.s.prabhu@gmail.com \
--cc=steve.capper@linaro.org \
--cc=suzuki.poulose@arm.com \
--cc=viresh.kumar@linaro.org \
--cc=wcohen@redhat.com \
--cc=will.deacon@arm.com \
--cc=yang.shi@linaro.org \
--cc=zlim.lnx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox