linux-kernel - Re: [PATCH v11 3/9] arm64: add copy_to/from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56E9350A.7010909@arm.com>
Date:	Wed, 16 Mar 2016 10:27:22 +0000
From:	James Morse <james.morse@....com>
To:	Pratyush Anand <panand@...hat.com>
CC:	David Long <dave.long@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
	William Cohen <wcohen@...hat.com>,
	Steve Capper <steve.capper@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Marc Zyngier <marc.zyngier@....com>,
	Dave P Martin <Dave.Martin@....com>,
	Mark Rutland <mark.rutland@....com>,
	Robin Murphy <Robin.Murphy@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Alex Bennée 
	<alex.bennee@...aro.org>, Yang Shi <yang.shi@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"Suzuki K. Poulose" <suzuki.poulose@....com>,
	Kees Cook <keescook@...omium.org>,
	Zi Shen Lim <zlim.lnx@...il.com>,
	John Blackwood <john.blackwood@...r.com>,
	Feng Kan <fkan@....com>,
	Balamurugan Shanmugam <bshanmugam@....com>,
	Vladimir Murzin <Vladimir.Murzin@....com>,
	Mark Salyzyn <salyzyn@...roid.com>,
	Petr Mladek <pmladek@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

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