All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Peter Collingbourne <pcc@google.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v3 20/23] fs: Allow copy_mount_options() to access user-space in a single pass
Date: Wed, 29 Apr 2020 12:58:59 +0100	[thread overview]
Message-ID: <20200429115858.GA10651@gaia> (raw)
In-Reply-To: <9544d86b-d445-3497-fbbf-56c590400f83@arm.com>

On Tue, Apr 28, 2020 at 07:16:29PM +0100, Kevin Brodsky wrote:
> On 21/04/2020 15:26, Catalin Marinas wrote:
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index a28e4db075ed..8febc50dfc5d 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -3025,13 +3025,16 @@ void *copy_mount_options(const void __user * data)
> >   	if (!copy)
> >   		return ERR_PTR(-ENOMEM);
> > -	size = PAGE_SIZE - offset_in_page(data);
> > +	size = PAGE_SIZE;
> > +	if (!arch_has_exact_copy_from_user(size))
> > +		size -= offset_in_page(data);
> > -	if (copy_from_user(copy, data, size)) {
> > +	if (copy_from_user(copy, data, size) == size) {
> >   		kfree(copy);
> >   		return ERR_PTR(-EFAULT);
> >   	}
> >   	if (size != PAGE_SIZE) {
> > +		WARN_ON(1);
> 
> I'm not sure I understand the rationale here. If we don't have exact
> copy_from_user for size, then we will attempt to copy up to the end of the
> page. Assuming this doesn't fault, we then want to carry on copying from the
> start of the next page, until we reach a total size of up to 4K. Why would
> we warn in that case? AIUI, if you don't have exact copy_from_user, there
> are 3 cases:
> 1. copy_from_user() returns size, we bail out.
> 2. copy_from_user() returns 0, we carry on copying from the next page.
> 3. copy_from_user() returns anything else, we return immediately.
> 
> I think you're not handling case 3 here.

(3) is still handled as (2) since the only check we have is whether
copy_from_user() returned size. Since size is not updated, it falls
through the second if block (where WARN_ON should have disappeared).

Thinking some more about this, I think it can be simplified without
adding arch_has_exact_copy_from_user(). We do have to guarantee on arm64
that a copy_from_user() to the end of a page (4K aligned, hence tag
granule aligned) is exact but that's just matching the current
semantics.

What about this new patch below, replacing the current one:

-------------8<-------------------------------
From cf9a1c9668ce77af3ef6589ee8038e91df127dab Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed, 15 Apr 2020 18:45:44 +0100
Subject: [PATCH] fs: Handle intra-page faults in copy_mount_options()

The copy_mount_options() function takes a user pointer argument but no
size. It tries to read up to a PAGE_SIZE. However, copy_from_user() is
not guaranteed to return all the accessible bytes if, for example, the
access crosses a page boundary and gets a fault on the second page. To
work around this, the current copy_mount_options() implementation
performs two copy_from_user() passes, first to the end of the current
page and the second to what's left in the subsequent page.

On arm64 with MTE enabled, access to a user page may trigger a fault
after part of the buffer has been copied (when the user pointer tag,
bits 56-59, no longer matches the allocation tag stored in memory).
Allow copy_mount_options() to handle such case by only returning -EFAULT
if the first copy_from_user() has not copied any bytes.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Will Deacon <will@kernel.org>
---
 fs/namespace.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index a28e4db075ed..51eecbd8ea89 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3016,7 +3016,7 @@ static void shrink_submounts(struct mount *mnt)
 void *copy_mount_options(const void __user * data)
 {
 	char *copy;
-	unsigned size;
+	unsigned size, left;
 
 	if (!data)
 		return NULL;
@@ -3027,11 +3027,22 @@ void *copy_mount_options(const void __user * data)
 
 	size = PAGE_SIZE - offset_in_page(data);
 
-	if (copy_from_user(copy, data, size)) {
+	/*
+	 * Attempt to copy to the end of the first user page. On success,
+	 * left == 0, copy the rest from the second user page (if it is
+	 * accessible).
+	 *
+	 * On architectures with intra-page faults (arm64 with MTE), the read
+	 * from the first page may fail after copying part of the user data
+	 * (left > 0 && left < size). Do not attempt the second copy in this
+	 * case as the end of the valid user buffer has already been reached.
+	 */
+	left = copy_from_user(copy, data, size);
+	if (left == size) {
 		kfree(copy);
 		return ERR_PTR(-EFAULT);
 	}
-	if (size != PAGE_SIZE) {
+	if (left == 0 && size != PAGE_SIZE) {
 		if (copy_from_user(copy + size, data + size, PAGE_SIZE - size))
 			memset(copy + size, 0, PAGE_SIZE - size);
 	}

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: linux-arch@vger.kernel.org,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Peter Collingbourne <pcc@google.com>,
	linux-mm@kvack.org, Alexander Viro <viro@zeniv.linux.org.uk>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 20/23] fs: Allow copy_mount_options() to access user-space in a single pass
Date: Wed, 29 Apr 2020 12:58:59 +0100	[thread overview]
Message-ID: <20200429115858.GA10651@gaia> (raw)
In-Reply-To: <9544d86b-d445-3497-fbbf-56c590400f83@arm.com>

On Tue, Apr 28, 2020 at 07:16:29PM +0100, Kevin Brodsky wrote:
> On 21/04/2020 15:26, Catalin Marinas wrote:
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index a28e4db075ed..8febc50dfc5d 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -3025,13 +3025,16 @@ void *copy_mount_options(const void __user * data)
> >   	if (!copy)
> >   		return ERR_PTR(-ENOMEM);
> > -	size = PAGE_SIZE - offset_in_page(data);
> > +	size = PAGE_SIZE;
> > +	if (!arch_has_exact_copy_from_user(size))
> > +		size -= offset_in_page(data);
> > -	if (copy_from_user(copy, data, size)) {
> > +	if (copy_from_user(copy, data, size) == size) {
> >   		kfree(copy);
> >   		return ERR_PTR(-EFAULT);
> >   	}
> >   	if (size != PAGE_SIZE) {
> > +		WARN_ON(1);
> 
> I'm not sure I understand the rationale here. If we don't have exact
> copy_from_user for size, then we will attempt to copy up to the end of the
> page. Assuming this doesn't fault, we then want to carry on copying from the
> start of the next page, until we reach a total size of up to 4K. Why would
> we warn in that case? AIUI, if you don't have exact copy_from_user, there
> are 3 cases:
> 1. copy_from_user() returns size, we bail out.
> 2. copy_from_user() returns 0, we carry on copying from the next page.
> 3. copy_from_user() returns anything else, we return immediately.
> 
> I think you're not handling case 3 here.

(3) is still handled as (2) since the only check we have is whether
copy_from_user() returned size. Since size is not updated, it falls
through the second if block (where WARN_ON should have disappeared).

Thinking some more about this, I think it can be simplified without
adding arch_has_exact_copy_from_user(). We do have to guarantee on arm64
that a copy_from_user() to the end of a page (4K aligned, hence tag
granule aligned) is exact but that's just matching the current
semantics.

What about this new patch below, replacing the current one:

-------------8<-------------------------------
From cf9a1c9668ce77af3ef6589ee8038e91df127dab Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed, 15 Apr 2020 18:45:44 +0100
Subject: [PATCH] fs: Handle intra-page faults in copy_mount_options()

The copy_mount_options() function takes a user pointer argument but no
size. It tries to read up to a PAGE_SIZE. However, copy_from_user() is
not guaranteed to return all the accessible bytes if, for example, the
access crosses a page boundary and gets a fault on the second page. To
work around this, the current copy_mount_options() implementation
performs two copy_from_user() passes, first to the end of the current
page and the second to what's left in the subsequent page.

On arm64 with MTE enabled, access to a user page may trigger a fault
after part of the buffer has been copied (when the user pointer tag,
bits 56-59, no longer matches the allocation tag stored in memory).
Allow copy_mount_options() to handle such case by only returning -EFAULT
if the first copy_from_user() has not copied any bytes.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Will Deacon <will@kernel.org>
---
 fs/namespace.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index a28e4db075ed..51eecbd8ea89 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3016,7 +3016,7 @@ static void shrink_submounts(struct mount *mnt)
 void *copy_mount_options(const void __user * data)
 {
 	char *copy;
-	unsigned size;
+	unsigned size, left;
 
 	if (!data)
 		return NULL;
@@ -3027,11 +3027,22 @@ void *copy_mount_options(const void __user * data)
 
 	size = PAGE_SIZE - offset_in_page(data);
 
-	if (copy_from_user(copy, data, size)) {
+	/*
+	 * Attempt to copy to the end of the first user page. On success,
+	 * left == 0, copy the rest from the second user page (if it is
+	 * accessible).
+	 *
+	 * On architectures with intra-page faults (arm64 with MTE), the read
+	 * from the first page may fail after copying part of the user data
+	 * (left > 0 && left < size). Do not attempt the second copy in this
+	 * case as the end of the valid user buffer has already been reached.
+	 */
+	left = copy_from_user(copy, data, size);
+	if (left == size) {
 		kfree(copy);
 		return ERR_PTR(-EFAULT);
 	}
-	if (size != PAGE_SIZE) {
+	if (left == 0 && size != PAGE_SIZE) {
 		if (copy_from_user(copy + size, data + size, PAGE_SIZE - size))
 			memset(copy + size, 0, PAGE_SIZE - size);
 	}

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-04-29 11:59 UTC|newest]

Thread overview: 165+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 14:25 [PATCH v3 00/23] arm64: Memory Tagging Extension user-space support Catalin Marinas
2020-04-21 14:25 ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 01/23] arm64: alternative: Allow alternative_insn to always issue the first instruction Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-27 16:57   ` Dave Martin
2020-04-27 16:57     ` Dave Martin
2020-04-28 11:43     ` Catalin Marinas
2020-04-28 11:43       ` Catalin Marinas
2020-04-29 10:26       ` Dave Martin
2020-04-29 10:26         ` Dave Martin
2020-04-29 14:04         ` Catalin Marinas
2020-04-29 14:04           ` Catalin Marinas
2020-04-29 14:04           ` Catalin Marinas
2020-05-04 14:47           ` Catalin Marinas
2020-05-04 14:47             ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 02/23] arm64: mte: system register definitions Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 03/23] arm64: mte: CPU feature detection and initial sysreg configuration Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 04/23] arm64: mte: Use Normal Tagged attributes for the linear map Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 05/23] arm64: mte: Assembler macros and default architecture for .S files Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 06/23] arm64: mte: Tags-aware clear_page() implementation Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 07/23] arm64: mte: Tags-aware copy_page() implementation Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 08/23] arm64: Tags-aware memcmp_pages() implementation Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 09/23] arm64: mte: Add specific SIGSEGV codes Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 10/23] arm64: mte: Handle synchronous and asynchronous tag check faults Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-23 10:38   ` Catalin Marinas
2020-04-23 10:38     ` Catalin Marinas
2020-04-27 16:58   ` Dave Martin
2020-04-27 16:58     ` Dave Martin
2020-04-28 13:43     ` Catalin Marinas
2020-04-28 13:43       ` Catalin Marinas
2020-04-29 10:26       ` Dave Martin
2020-04-29 10:26         ` Dave Martin
2020-04-21 14:25 ` [PATCH v3 11/23] mm: Introduce arch_calc_vm_flag_bits() Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 12/23] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 13/23] mm: Introduce arch_validate_flags() Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 14/23] arm64: mte: Validate the PROT_MTE request via arch_validate_flags() Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 15/23] mm: Allow arm64 mmap(PROT_MTE) on RAM-based files Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 16/23] arm64: mte: Allow user control of the tag check mode via prctl() Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 17/23] arm64: mte: Allow user control of the generated random tags " Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-21 14:25 ` [PATCH v3 18/23] arm64: mte: Restore the GCR_EL1 register after a suspend Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-23 15:23   ` Lorenzo Pieralisi
2020-04-23 15:23     ` Lorenzo Pieralisi
2020-04-21 14:25 ` [PATCH v3 19/23] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support Catalin Marinas
2020-04-21 14:25   ` Catalin Marinas
2020-04-24 23:28   ` Peter Collingbourne
2020-04-24 23:28     ` [PATCH v3 19/23] arm64: mte: Add PTRACE_{PEEK, POKE}MTETAGS support Peter Collingbourne
2020-04-29 10:27   ` [PATCH v3 19/23] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support Kevin Brodsky
2020-04-29 10:27     ` Kevin Brodsky
2020-04-29 15:24     ` Catalin Marinas
2020-04-29 15:24       ` Catalin Marinas
2020-04-29 16:46   ` Dave Martin
2020-04-29 16:46     ` Dave Martin
2020-04-30 10:21     ` Catalin Marinas
2020-04-30 10:21       ` Catalin Marinas
2020-05-04 16:40       ` Dave Martin
2020-05-04 16:40         ` Dave Martin
2020-05-05 18:03   ` Luis Machado
2020-05-05 18:03     ` Luis Machado
2020-05-12 19:05   ` Luis Machado
2020-05-12 19:05     ` Luis Machado
2020-05-13 10:48     ` Catalin Marinas
2020-05-13 10:48       ` Catalin Marinas
2020-05-13 12:52       ` Luis Machado
2020-05-13 12:52         ` Luis Machado
2020-05-13 14:11         ` Catalin Marinas
2020-05-13 14:11           ` Catalin Marinas
2020-05-13 15:09           ` Luis Machado
2020-05-13 15:09             ` Luis Machado
2020-05-13 16:45             ` Luis Machado
2020-05-13 16:45               ` Luis Machado
2020-05-13 17:11               ` Catalin Marinas
2020-05-13 17:11                 ` Catalin Marinas
2020-05-18 16:47               ` Dave Martin
2020-05-18 16:47                 ` Dave Martin
2020-05-18 17:12                 ` Luis Machado
2020-05-18 17:12                   ` Luis Machado
2020-05-19 16:10                   ` Catalin Marinas
2020-05-19 16:10                     ` Catalin Marinas
2020-04-21 14:26 ` [PATCH v3 20/23] fs: Allow copy_mount_options() to access user-space in a single pass Catalin Marinas
2020-04-21 14:26   ` Catalin Marinas
2020-04-21 15:29   ` Al Viro
2020-04-21 15:29     ` Al Viro
2020-04-21 16:45     ` Catalin Marinas
2020-04-21 16:45       ` Catalin Marinas
2020-04-27 16:56   ` Dave Martin
2020-04-27 16:56     ` Dave Martin
2020-04-28 14:06     ` Catalin Marinas
2020-04-28 14:06       ` Catalin Marinas
2020-04-29 10:28       ` Dave Martin
2020-04-29 10:28         ` Dave Martin
2020-04-28 18:16   ` Kevin Brodsky
2020-04-28 18:16     ` Kevin Brodsky
2020-04-28 19:40     ` Catalin Marinas
2020-04-28 19:40       ` Catalin Marinas
2020-04-29 11:58     ` Catalin Marinas [this message]
2020-04-29 11:58       ` Catalin Marinas
2020-04-28 19:36   ` Catalin Marinas
2020-04-28 19:36     ` Catalin Marinas
2020-04-29 10:26   ` Dave Martin
2020-04-29 10:26     ` Dave Martin
2020-04-29 13:52     ` Catalin Marinas
2020-04-29 13:52       ` Catalin Marinas
2020-05-04 16:40       ` Dave Martin
2020-05-04 16:40         ` Dave Martin
2020-04-21 14:26 ` [PATCH v3 21/23] arm64: mte: Check the DT memory nodes for MTE support Catalin Marinas
2020-04-21 14:26   ` Catalin Marinas
2020-04-24 13:57   ` Catalin Marinas
2020-04-24 13:57     ` Catalin Marinas
2020-04-24 16:17     ` Catalin Marinas
2020-04-24 16:17       ` Catalin Marinas
2020-04-27 11:14       ` Suzuki K Poulose
2020-04-27 11:14         ` Suzuki K Poulose
2020-04-21 14:26 ` [PATCH v3 22/23] arm64: mte: Kconfig entry Catalin Marinas
2020-04-21 14:26   ` Catalin Marinas
2020-04-21 14:26 ` [PATCH v3 23/23] arm64: mte: Add Memory Tagging Extension documentation Catalin Marinas
2020-04-21 14:26   ` Catalin Marinas
2020-04-29 16:47   ` Dave Martin
2020-04-29 16:47     ` Dave Martin
2020-04-30 16:23     ` Catalin Marinas
2020-04-30 16:23       ` Catalin Marinas
2020-05-04 16:46       ` Dave Martin
2020-05-04 16:46         ` Dave Martin
2020-05-11 16:40         ` Catalin Marinas
2020-05-11 16:40           ` Catalin Marinas
2020-05-13 15:48           ` Dave Martin
2020-05-13 15:48             ` Dave Martin
2020-05-14 11:37             ` Catalin Marinas
2020-05-14 11:37               ` Catalin Marinas
2020-05-15 10:38               ` Catalin Marinas
2020-05-15 10:38                 ` Catalin Marinas
2020-05-15 11:14                 ` Szabolcs Nagy
2020-05-15 11:14                   ` Szabolcs Nagy
2020-05-15 11:27                   ` Catalin Marinas
2020-05-15 11:27                     ` Catalin Marinas
2020-05-15 12:04                     ` Szabolcs Nagy
2020-05-15 12:04                       ` Szabolcs Nagy
2020-05-15 12:13                       ` Catalin Marinas
2020-05-15 12:13                         ` Catalin Marinas
2020-05-15 12:53                         ` Szabolcs Nagy
2020-05-15 12:53                           ` Szabolcs Nagy
2020-05-18 16:52                           ` Dave Martin
2020-05-18 16:52                             ` Dave Martin
2020-05-18 17:13               ` Catalin Marinas
2020-05-18 17:13                 ` Catalin Marinas
2020-05-05 10:32   ` Szabolcs Nagy
2020-05-05 10:32     ` Szabolcs Nagy
2020-05-05 17:30     ` Catalin Marinas
2020-05-05 17:30       ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200429115858.GA10651@gaia \
    --to=catalin.marinas@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=andreyknvl@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=pcc@google.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.