Received: by 2002:ac0:8bc7:0:0:0:0:0 with SMTP id o7csp62775ima; Wed, 6 Feb 2019 21:05:08 -0800 (PST) X-Google-Smtp-Source: AHgI3IabDtMHCkvaFjQiUDKpd0TG4WKrSu7lFV3Hx+mPKQ4pYh+QjVt9yvOr7UInN0hw4DF4n4j2 X-Received: by 2002:a17:902:724a:: with SMTP id c10mr14897089pll.51.1549515908585; Wed, 06 Feb 2019 21:05:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549515908; cv=none; d=google.com; s=arc-20160816; b=Z5fv/QGbVrmJwS1keMY20cUNNHyQz1FbapOMxUIl3MfUNFIbD3RxMo/UjvAUbzFUFk hrz9sTH9oJxKhEFuN0i7KCSprPQL0DMX87pHA5VGrjOUAx4S5MZlQ8xIWVVPvX3uhfFl B6+Imj0CUwjAivEO3g1hRExNF8ziLKAO6R38KiXL36e3a1OalD19cD9qgSFL6ms/5cAl S84ILRfsHX/keVbJqPU7gm9pcEIFl0slnqwkpQbwbBgi+TBcquHrmAWtF+OgfuUbHjee +qlD50Wh4lvI8VOeWNCg5ksFM8Mvv8veaXYRKlp2qadVGET2cfxBYq1J1VwDTzjuO5fU aV8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=x+asooKvJQwJjAfphAzY2OuJWCR5RVUO3LHg2DwDj6g=; b=GZrCprg1JG/hbqIioGguS+UBdb0UyiTPWtJlkj90o1/w0xGUOD0gyxl09ZiZQkcuBB bp9kNuz4Exi4ZBkzbgRqEcaTxoUQtywoL0JviPYPGUswlB2FTq5effbtgrIwZ04TZVCD L3111Q9bkIQxQig0tDgJUCnxPfPXgNC58AZ2FOan17szge+7QFSjlh/rbphxPQ+qpi3W O1j+HrygluN185Ypvx9bJxYZiiiG14jY3BRJ+gJuUenSJQRpk6aBxx+bq2+nfW3rQQ8B tIcoBM5AWwfDvi59rl+jghN9p0T+67lkjhmHdUpzeB8MzR4fZeK9hZ+F7NfbaPmhCLX5 rl7g== 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 q20si7904539pll.255.2019.02.06.21.04.51; Wed, 06 Feb 2019 21:05:08 -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 S1726325AbfBGFEK (ORCPT + 99 others); Thu, 7 Feb 2019 00:04:10 -0500 Received: from ozlabs.org ([203.11.71.1]:55265 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725910AbfBGFEK (ORCPT ); Thu, 7 Feb 2019 00:04:10 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43w5ng2hX4z9s6w; Thu, 7 Feb 2019 16:04:07 +1100 (AEDT) From: Michael Ellerman To: Murilo Opsfelder Araujo , Christophe Leroy Cc: Kees Cook , Andrew Morton , Benjamin Herrenschmidt , Paul Mackerras , Mike Rapoport , linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] mm: add probe_user_read() In-Reply-To: <20190205174242.GA24427@kermit.br.ibm.com> References: <39fb6c5a191025378676492e140dc012915ecaeb.1547652372.git.christophe.leroy@c-s.fr> <20190205174242.GA24427@kermit.br.ibm.com> Date: Thu, 07 Feb 2019 16:04:07 +1100 Message-ID: <87zhr8jik8.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Murilo Opsfelder Araujo writes: >> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h >> index 37b226e8df13..ef99edd63da3 100644 >> --- 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 >> + * >> + * 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. >> + * >> + * Returns: 0 on success, -EFAULT on error. >> + */ >> + >> +#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; > > Hopefully, there is still time for a minor comment. > > Do we need to differentiate the returned error here, e.g.: return > -EACCES? > > I wonder if there will be situations where callers need to know why > probe_user_read() failed. It's pretty standard to return EFAULT when an access_ok() check fails, so I think using EFAULT here is the safest option. If we used EACCES we'd need to be more careful about converting code to use this helper, as doing so would potentially cause the error value to change, which in some cases is not OK. cheers