From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm64: add alignment fault hanling
Date: Tue, 16 Feb 2016 23:04:12 +0000 [thread overview]
Message-ID: <20160216230409.GA24379@MBP.local> (raw)
In-Reply-To: <56C39538.6090009@linux.intel.com>
On Tue, Feb 16, 2016 at 01:31:36PM -0800, Arjan van de Ven wrote:
> On 2/16/2016 10:50 AM, Linus Torvalds wrote:
> >On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>[replying to self and adding some x86 people]
> >>
> >>Background: Euntaik reports a problem where userspace has ended up with
> >>a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> >>PCI memory bar from someplace in /sys). strncpy_from_user happens with
> >>the word-at-a-time implementation, and we end up reading into the MMIO
> >>page.
>
> how does this work if the adjacent page is not accessible?
do_strncpy_from_user() assumes by default that it can read a word at a
time using get_user() but checks its return value in case it failed and
falls back to byte at a time. What happens on arm64 is that for
alignment faults we don't have a handler that would search the exception
table and run the get_user() fixup.
> isn't the general rule for such basic functions "don't touch memory
> unless you KNOW it is there"
Well, user access routines are in general safe with this via the
exception handling + fixup mechanism (which usually returns -EFAULT).
That's what do_strncpy_from_user() tries to do by optimising away the
boundary checks.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Will Deacon <will.deacon@arm.com>,
"vladimir.murzin@arm.com" <vladimir.murzin@arm.com>,
"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"salyzyn@android.com" <salyzyn@android.com>,
"riandrews@android.com" <riandrews@android.com>,
"james.morse@arm.com" <james.morse@arm.com>,
EunTaik Lee <eun.taik.lee@samsung.com>,
Peter Anvin <hpa@zytor.com>, Robin Murphy <robin.murphy@arm.com>,
"Dave.Martin@arm.com" <Dave.Martin@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64: add alignment fault hanling
Date: Tue, 16 Feb 2016 23:04:12 +0000 [thread overview]
Message-ID: <20160216230409.GA24379@MBP.local> (raw)
In-Reply-To: <56C39538.6090009@linux.intel.com>
On Tue, Feb 16, 2016 at 01:31:36PM -0800, Arjan van de Ven wrote:
> On 2/16/2016 10:50 AM, Linus Torvalds wrote:
> >On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>[replying to self and adding some x86 people]
> >>
> >>Background: Euntaik reports a problem where userspace has ended up with
> >>a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> >>PCI memory bar from someplace in /sys). strncpy_from_user happens with
> >>the word-at-a-time implementation, and we end up reading into the MMIO
> >>page.
>
> how does this work if the adjacent page is not accessible?
do_strncpy_from_user() assumes by default that it can read a word at a
time using get_user() but checks its return value in case it failed and
falls back to byte at a time. What happens on arm64 is that for
alignment faults we don't have a handler that would search the exception
table and run the get_user() fixup.
> isn't the general rule for such basic functions "don't touch memory
> unless you KNOW it is there"
Well, user access routines are in general safe with this via the
exception handling + fixup mechanism (which usually returns -EFAULT).
That's what do_strncpy_from_user() tries to do by optimising away the
boundary checks.
--
Catalin
next prev parent reply other threads:[~2016-02-16 23:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 4:44 [PATCH v2] arm64: add alignment fault hanling EunTaik Lee
2016-02-16 4:44 ` EunTaik Lee
2016-02-16 10:31 ` Will Deacon
2016-02-16 10:31 ` Will Deacon
2016-02-16 10:57 ` Robin Murphy
2016-02-16 10:57 ` Robin Murphy
2016-02-16 12:21 ` Catalin Marinas
2016-02-16 12:21 ` Catalin Marinas
2016-02-16 16:00 ` Will Deacon
2016-02-16 16:00 ` Will Deacon
2016-02-16 17:04 ` Will Deacon
2016-02-16 17:04 ` Will Deacon
2016-02-16 18:50 ` Linus Torvalds
2016-02-16 18:50 ` Linus Torvalds
2016-02-16 21:31 ` Arjan van de Ven
2016-02-16 21:31 ` Arjan van de Ven
2016-02-16 23:04 ` Catalin Marinas [this message]
2016-02-16 23:04 ` Catalin Marinas
[not found] ` <CA+55aFz+ttJoEG_WkpkwV=+Wunzxpj9NoHobq-8oFZS0HEEyeA@mail.gmail.com>
2016-02-17 0:28 ` Linus Torvalds
2016-02-17 0:28 ` Linus Torvalds
2016-02-19 18:14 ` Catalin Marinas
2016-02-19 18:14 ` Catalin Marinas
2016-02-19 22:09 ` Linus Torvalds
2016-02-19 22:09 ` Linus Torvalds
2016-02-16 17:09 ` Catalin Marinas
2016-02-16 17:09 ` Catalin Marinas
2016-02-16 17:11 ` Catalin Marinas
2016-02-16 17:11 ` 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=20160216230409.GA24379@MBP.local \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.