From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752038AbdBOMJy (ORCPT ); Wed, 15 Feb 2017 07:09:54 -0500 Received: from foss.arm.com ([217.140.101.70]:54844 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751775AbdBOMJx (ORCPT ); Wed, 15 Feb 2017 07:09:53 -0500 Message-ID: <58A4450C.3040602@arm.com> Date: Wed, 15 Feb 2017 12:09:48 +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: Sodagudi Prasad , shijie.huang@arm.com CC: catalin.marinas@arm.com, will.deacon@arm.com, mark.rutland@arm.com, akpm@linux-foundation.org, sandeepa.s.prabhu@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Looking more details and reasons for using orig_add_limit. References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Prasad, On 15/02/17 05:52, Sodagudi Prasad wrote: > When any sys call is made from user space orig_addr_limit will be zero and after > that driver is calling set_fs(KERNEL_DS) and then copy_to_user() to user space > memory. Don't do this, its exactly the case PAN+UAO and the code you pointed to are designed to catch. Accessing userspace needs doing carefully, setting USER_DS and using the put_user()/copy_to_user() accessors are the required steps. Which driver is doing this? Is it in mainline? > If there is permission fault for user space address the above condition > is leading to kernel crash. Because orig_add_limit is having KERNEL_DS as set_fs > called before copy_to_user(). > > 1) So I would like to understand that, is that user space pointer leading to > permission fault not correct(condition_1) in this scenario? The correct thing has happened here. To access user space set_fs(USER_DS) first. (and set it back to whatever it was afterwards). > 2) Are there any corner cases where these if conditions (condition_1 and > condition2) would lead to kernel crash ? If you do this on behalf of a user space process the kernel will try to clean up as best it can and carry on. If you access user space from an interrupt handler or from a kernel thread you can expect the kernel to panic(). > 3) What are all scenarios these if conditions (condition_1 and condition2) > would like to take care? I'm not sure I understand this question. PAN prevents general kernel code from accessing user space, you have to use the accessors. When you have UAO too, it can enforce the set_fs() limit as PAN will generate permission faults when the accessors touch the kernel/user-space after setting the other set_fs() limit. I hope this helps! Thanks, James