From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm64: print a fault message when attempting to write RO memory
Date: Mon, 20 Feb 2017 11:10:10 +0000 [thread overview]
Message-ID: <58AACE92.4040608@arm.com> (raw)
In-Reply-To: <148734678579.30076.8827985106565313944@sboyd-linaro>
Hi Stephen,
On 17/02/17 15:53, Stephen Boyd wrote:
> Quoting James Morse (2017-02-17 03:00:39)
>> On 17/02/17 01:19, Stephen Boyd wrote:
>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>> index 156169c6981b..8bd4e7f11c70 100644
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -177,9 +193,19 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
>>> * No handler, we'll have to terminate things with extreme prejudice.
>>> */
>>> bust_spinlocks(1);
>>> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
>>> - (addr < PAGE_SIZE) ? "NULL pointer dereference" :
>>> - "paging request", addr);
>>> +
>>> + if (is_permission_fault(esr, regs)) {
>>
>> is_permission_fault() was previously guarded with a 'addr<USER_DS' check, this
>> is because it assumes software-PAN is relevant.
>>
>> The corner case is when the kernel accesses TTBR1-mapped memory while
>> software-PAN happens to have swivelled TTBR0. Translation faults will be matched
>> by is_permission_fault(), but permission faults won't.
>
> If I understand correctly, and I most definitely don't because there are
> quite a few combinations, you're saying that __do_kernel_fault() could
> be called if the kernel attempts to access some userspace address with
> software PAN? That won't be caught in do_page_fault() with the previous
> is_permission_fault() check?
You're right the user-address side of things will get caught in do_page_fault().
I was trying to badly-explain 'is_permission_fault(esr)' isn't as general
purpose as its name and prototype suggest, it only gives the results that the
PAN checks expect when called with a user address.
>> Juggling is_permission_fault() to look something like:
>> ---%<---
>> if (fsc_type == ESR_ELx_FSC_PERM)
>> return true;
>>
>> if (addr < USER_DS && system_uses_ttbr0_pan())
>> return fsc_type == ESR_ELx_FSC_FAULT &&
>> (regs->pstate & PSR_PAN_BIT);
>>
>> return false;
>> ---%<---
>> ... should fix this.
>
> But we don't need to check ec anymore?
Sorry, I was being sloppy, something like the above could replace the if/else
block at the end of is_permission_fault(). You're right we still need the ec check!
Thanks,
James
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Laura Abbott <labbott@redhat.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory
Date: Mon, 20 Feb 2017 11:10:10 +0000 [thread overview]
Message-ID: <58AACE92.4040608@arm.com> (raw)
In-Reply-To: <148734678579.30076.8827985106565313944@sboyd-linaro>
Hi Stephen,
On 17/02/17 15:53, Stephen Boyd wrote:
> Quoting James Morse (2017-02-17 03:00:39)
>> On 17/02/17 01:19, Stephen Boyd wrote:
>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>> index 156169c6981b..8bd4e7f11c70 100644
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -177,9 +193,19 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
>>> * No handler, we'll have to terminate things with extreme prejudice.
>>> */
>>> bust_spinlocks(1);
>>> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
>>> - (addr < PAGE_SIZE) ? "NULL pointer dereference" :
>>> - "paging request", addr);
>>> +
>>> + if (is_permission_fault(esr, regs)) {
>>
>> is_permission_fault() was previously guarded with a 'addr<USER_DS' check, this
>> is because it assumes software-PAN is relevant.
>>
>> The corner case is when the kernel accesses TTBR1-mapped memory while
>> software-PAN happens to have swivelled TTBR0. Translation faults will be matched
>> by is_permission_fault(), but permission faults won't.
>
> If I understand correctly, and I most definitely don't because there are
> quite a few combinations, you're saying that __do_kernel_fault() could
> be called if the kernel attempts to access some userspace address with
> software PAN? That won't be caught in do_page_fault() with the previous
> is_permission_fault() check?
You're right the user-address side of things will get caught in do_page_fault().
I was trying to badly-explain 'is_permission_fault(esr)' isn't as general
purpose as its name and prototype suggest, it only gives the results that the
PAN checks expect when called with a user address.
>> Juggling is_permission_fault() to look something like:
>> ---%<---
>> if (fsc_type == ESR_ELx_FSC_PERM)
>> return true;
>>
>> if (addr < USER_DS && system_uses_ttbr0_pan())
>> return fsc_type == ESR_ELx_FSC_FAULT &&
>> (regs->pstate & PSR_PAN_BIT);
>>
>> return false;
>> ---%<---
>> ... should fix this.
>
> But we don't need to check ec anymore?
Sorry, I was being sloppy, something like the above could replace the if/else
block at the end of is_permission_fault(). You're right we still need the ec check!
Thanks,
James
next prev parent reply other threads:[~2017-02-20 11:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 1:19 [PATCH v2] arm64: print a fault message when attempting to write RO memory Stephen Boyd
2017-02-17 1:19 ` Stephen Boyd
2017-02-17 11:00 ` James Morse
2017-02-17 11:00 ` James Morse
2017-02-17 15:53 ` Stephen Boyd
2017-02-20 11:10 ` James Morse [this message]
2017-02-20 11:10 ` James Morse
2017-02-25 1:39 ` Stephen Boyd
2017-02-25 1:39 ` Stephen Boyd
2017-03-23 14:22 ` Will Deacon
2017-03-23 14:22 ` Will Deacon
2017-04-04 6:28 ` Stephen Boyd
2017-04-04 6:28 ` Stephen Boyd
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=58AACE92.4040608@arm.com \
--to=james.morse@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.