From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/7] arm64: Handle faults caused by inadvertent user access with PAN enabled
Date: Fri, 16 Sep 2016 12:33:25 +0100 [thread overview]
Message-ID: <20160916113325.GB21702@leverpostej> (raw)
In-Reply-To: <1473788797-10879-6-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 06:46:35PM +0100, Catalin Marinas wrote:
> When TTBR0_EL1 is set to the reserved page, an erroneous kernel access
> to user space would generate a translation fault. This patch adds the
> checks for the software-set PSR_PAN_BIT to emulate a permission fault
> and report it accordingly.
Why do we need to treat this case as a permission fault? It looks like a
fault that wasn't a deliberate uaccess (which thus doesn't have a fixup
handler) should have do_page_fault call __do_kernel_fault, where we
should die().
Is this just for more consistent reporting of erroneous accesses to user
memory? Or does this fix some other issue?
> This patch also updates the description of the synchronous external
> aborts on translation table walks.
This sounds fine, though it might be better as a separate/preparatory
patch.
> -static inline bool is_permission_fault(unsigned int esr)
> +static inline bool is_permission_fault(unsigned int esr, struct pt_regs *regs)
> {
> unsigned int ec = ESR_ELx_EC(esr);
> unsigned int fsc_type = esr & ESR_ELx_FSC_TYPE;
>
> - return (ec == ESR_ELx_EC_DABT_CUR && fsc_type == ESR_ELx_FSC_PERM) ||
> - (ec == ESR_ELx_EC_IABT_CUR && fsc_type == ESR_ELx_FSC_PERM);
> + if (ec != ESR_ELx_EC_DABT_CUR && ec != ESR_ELx_EC_IABT_CUR)
> + return false;
> +
> + if (system_uses_ttbr0_pan())
> + return fsc_type == ESR_ELx_FSC_FAULT &&
> + (regs->pstate & PSR_PAN_BIT);
> + else
> + return fsc_type == ESR_ELx_FSC_PERM;
> }
Since the entry code will clear the PAN bit in the SPSR when we see the
reserved ASID, faults in EFI runtime services will still be correctly
reported, though that's somewhat subtle (and it took me a while to
convince myself that was the case).
Also, I think that faults elsewhere may be misreported, e.g. in cold
entry to kernel paths (idle, hotplug) where we have a global mapping in
TTBR0, and it looks like we're using the reserved ASID.
I'm not immediately sure how to distinguish those cases.
Thanks,
Mark.
next prev parent reply other threads:[~2016-09-16 11:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 17:46 [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching Catalin Marinas
2016-09-13 17:46 ` [PATCH v3 1/7] arm64: Factor out PAN enabling/disabling into separate uaccess_* macros Catalin Marinas
2016-09-15 15:10 ` Mark Rutland
2016-09-13 17:46 ` [PATCH v3 2/7] arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro Catalin Marinas
2016-09-15 15:19 ` Mark Rutland
2016-09-13 17:46 ` [PATCH v3 3/7] arm64: Introduce uaccess_{disable, enable} functionality based on TTBR0_EL1 Catalin Marinas
2016-09-13 20:45 ` [PATCH v3 3/7] arm64: Introduce uaccess_{disable,enable} " Kees Cook
2016-09-14 8:52 ` Mark Rutland
2016-09-14 16:27 ` [kernel-hardening] " Kees Cook
2016-09-13 17:46 ` [PATCH v3 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution Catalin Marinas
2016-09-14 16:45 ` Will Deacon
2016-09-13 17:46 ` [PATCH v3 5/7] arm64: Handle faults caused by inadvertent user access with PAN enabled Catalin Marinas
2016-09-16 11:33 ` Mark Rutland [this message]
2016-09-16 15:55 ` Catalin Marinas
2016-09-13 17:46 ` [PATCH v3 6/7] arm64: xen: Enable user access before a privcmd hvc call Catalin Marinas
2016-09-13 17:46 ` [PATCH v3 7/7] arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN Catalin Marinas
2016-09-14 10:13 ` [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching Ard Biesheuvel
2016-09-14 10:27 ` Mark Rutland
2016-09-14 10:30 ` Ard Biesheuvel
2016-09-14 10:36 ` Mark Rutland
2016-09-14 10:48 ` Mark Rutland
2016-09-14 20:54 ` [kernel-hardening] " David Brown
2016-09-15 9:52 ` Catalin Marinas
2016-09-15 16:20 ` Mark Rutland
2016-09-15 16:41 ` Mark Rutland
2016-09-29 22:44 ` [kernel-hardening] " Sami Tolvanen
2016-09-30 18:42 ` Kees Cook
2016-10-27 14:54 ` Catalin Marinas
2016-10-27 21:23 ` Kees Cook
2016-10-14 21:44 ` Kees Cook
2016-10-15 14:35 ` Catalin Marinas
2016-10-16 2:04 ` Kees Cook
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=20160916113325.GB21702@leverpostej \
--to=mark.rutland@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox