Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5116972imu; Tue, 8 Jan 2019 11:50:14 -0800 (PST) X-Google-Smtp-Source: ALg8bN7c5fEM/Nqfyc5ugtZR4IHQ4F7vlxXZsUH/QdgIjkE092b41GPw6GM0xy1g2MEwQdtnAuOe X-Received: by 2002:a62:7652:: with SMTP id r79mr3117795pfc.241.1546977013930; Tue, 08 Jan 2019 11:50:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546977013; cv=none; d=google.com; s=arc-20160816; b=KKQRnZsk1j9m26sj15HY9WzRdtNZ5XPC9xySqClkSlr6qUHXNtaqKfh8qpDGnpLYMA mAItP4Sc6B+ueOxue2v5DRKi1iFAt7+SrQBeSQjS6cftz+bCLy1U7Ab3CIbU2sQqjsqd 5qd5tB/RjJZlqMNEvN6UKeKuLWpGZ5n+d6lqM8ZUJEQo3u5FydNOemWtIWIDhx4skkKd JP7u+NKU1IMgXyg1WyrsPEP/r7jR6EN2dwkjWPus2CKTKgK+VugG0i+Iecrozo5u9atr bvJdNIXRXPeROXM6YYcFKLwwwdd54IsgXKIiyhJG1TFPW5WfL8hIsJjciMFFxIJS4ZJV v0cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=kxFixqFk5y9/Tg+jPwqWGrjq3B9LYZreZ0j4+dRR530=; b=ALIis4JjbB8NwuvicUsSLPzh7gXcpuq4osjT67+N6PuOqAwnEpZkLKfdSMlA2UbFGs iTi+fo+Dw29cnh3AacygRBKRC34rmzu2T43IpTLecyJXalVYJ7cRQPTftTTPwYsxGuYr iRjrJT7xwcNhQY8bzJLwukW/cus+1D0gCPBdI2+q4Ihrfa7i80uzy17JK8OWoj2L2NXE Vzg6ceAXRuKg4ctGiTd4n0HkF8mvHSmZT3EsOXsQekgQRmQIZgY3qnOpD2/MRqc7M3QO UqOUMNFPHVa7wUenw+u1elF7zV6uJ7mf+AV9ln05euzJqf1NVd/Caytc7f0ssWnBAhWz u5JQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s19si64369331plp.151.2019.01.08.11.49.57; Tue, 08 Jan 2019 11:50:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732773AbfAHTsH (ORCPT + 99 others); Tue, 8 Jan 2019 14:48:07 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:50106 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728484AbfAHTsG (ORCPT ); Tue, 8 Jan 2019 14:48:06 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id DADFE891; Tue, 8 Jan 2019 19:48:04 +0000 (UTC) Date: Tue, 8 Jan 2019 11:48:03 -0800 From: Andrew Morton To: Christophe Leroy Cc: Kees Cook , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Mike Rapoport , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org Subject: Re: [PATCH v2 1/2] mm: add probe_user_read() Message-Id: <20190108114803.583f203b86d4a368ac9796f3@linux-foundation.org> In-Reply-To: <0b0db24e18063076e9d9f4e376994af83da05456.1546932949.git.christophe.leroy@c-s.fr> References: <0b0db24e18063076e9d9f4e376994af83da05456.1546932949.git.christophe.leroy@c-s.fr> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019 07:37:44 +0000 (UTC) Christophe Leroy wrote: > In powerpc code, there are several places implementing safe > access to user data. This is sometimes implemented using > probe_kernel_address() with additional access_ok() verification, > sometimes with get_user() enclosed in a pagefault_disable()/enable() > pair, etc. : > show_user_instructions() > bad_stack_expansion() > p9_hmi_special_emu() > fsl_pci_mcheck_exception() > read_user_stack_64() > read_user_stack_32() on PPC64 > read_user_stack_32() on PPC32 > power_pmu_bhrb_to() > > In the same spirit as probe_kernel_read(), this patch adds > probe_user_read(). > > probe_user_read() does the same as probe_kernel_read() but > first checks that it is really a user address. > > ... > > --- a/include/linux/uaccess.h > +++ b/include/linux/uaccess.h > @@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count); > #define probe_kernel_address(addr, retval) \ > probe_kernel_read(&retval, addr, sizeof(retval)) > > +/** > + * probe_user_read(): safely attempt to read from a user location > + * @dst: pointer to the buffer that shall take the data > + * @src: address to read from > + * @size: size of the data chunk > + * > + * Returns: 0 on success, -EFAULT on error. > + * > + * Safely read from address @src to the buffer at @dst. If a kernel fault > + * happens, handle that and return -EFAULT. > + * > + * We ensure that the copy_from_user is executed in atomic context so that > + * do_page_fault() doesn't attempt to take mmap_sem. This makes > + * probe_user_read() suitable for use within regions where the caller > + * already holds mmap_sem, or other locks which nest inside mmap_sem. > + */ > + > +#ifndef probe_user_read > +static __always_inline long probe_user_read(void *dst, const void __user *src, > + size_t size) > +{ > + long ret; > + > + if (!access_ok(src, size)) > + return -EFAULT; > + > + pagefault_disable(); > + ret = __copy_from_user_inatomic(dst, src, size); > + pagefault_enable(); > + > + return ret ? -EFAULT : 0; > +} > +#endif Why was the __always_inline needed? This function is pretty large. Why is it inlined?