From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966290AbcCPK24 (ORCPT ); Wed, 16 Mar 2016 06:28:56 -0400 Received: from foss.arm.com ([217.140.101.70]:41061 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752262AbcCPK2y (ORCPT ); Wed, 16 Mar 2016 06:28:54 -0400 Message-ID: <56E9350A.7010909@arm.com> Date: Wed, 16 Mar 2016 10:27:22 +0000 From: James Morse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Pratyush Anand CC: David Long , Catalin Marinas , Will Deacon , Sandeepa Prabhu , William Cohen , Steve Capper , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Marc Zyngier , Dave P Martin , Mark Rutland , Robin Murphy , Ard Biesheuvel , Jens Wiklander , Christoffer Dall , =?windows-1252?Q?Alex_?= =?windows-1252?Q?Benn=E9e?= , Yang Shi , Greg Kroah-Hartman , Viresh Kumar , "Suzuki K. Poulose" , Kees Cook , Zi Shen Lim , John Blackwood , Feng Kan , Balamurugan Shanmugam , Vladimir Murzin , Mark Salyzyn , Petr Mladek , Andrew Morton , Mark Brown Subject: Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist References: <1457501543-24197-1-git-send-email-dave.long@linaro.org> <1457501543-24197-4-git-send-email-dave.long@linaro.org> <56E858D8.8030300@arm.com> <20160316054329.GC28915@dhcppc6.redhat.com> In-Reply-To: <20160316054329.GC28915@dhcppc6.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: james.morse@arm.com (James Morse) Date: Wed, 16 Mar 2016 10:27:22 +0000 Subject: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist In-Reply-To: <20160316054329.GC28915@dhcppc6.redhat.com> References: <1457501543-24197-1-git-send-email-dave.long@linaro.org> <1457501543-24197-4-git-send-email-dave.long@linaro.org> <56E858D8.8030300@arm.com> <20160316054329.GC28915@dhcppc6.redhat.com> Message-ID: <56E9350A.7010909@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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