From: Will Deacon <will.deacon@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Kees Cook <keescook@chromium.org>,
Mark Rutland <mark.rutland@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH v3 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution
Date: Wed, 14 Sep 2016 17:45:11 +0100 [thread overview]
Message-ID: <20160914164511.GJ19622@arm.com> (raw)
In-Reply-To: <1473788797-10879-5-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 06:46:34PM +0100, Catalin Marinas wrote:
> When the TTBR0 PAN feature is enabled, the kernel entry points need to
> disable access to TTBR0_EL1. The PAN status of the interrupted context
> is stored as part of the saved pstate, reusing the PSR_PAN_BIT (22).
> Restoring access to TTBR0_PAN is done on exception return if returning
> to user or returning to a context where PAN was disabled.
>
> Context switching via switch_mm() must defer the update of TTBR0_EL1
> until a return to user or an explicit uaccess_enable() call.
>
> Special care needs to be taken for two cases where TTBR0_EL1 is set
> outside the normal kernel context switch operation: EFI run-time
> services (via efi_set_pgd) and CPU suspend (via cpu_(un)install_idmap).
> Code has been added to avoid deferred TTBR0_EL1 switching as in
> switch_mm() and restore the reserved TTBR0_EL1 when uninstalling the
> special TTBR0_EL1.
>
> This patch also removes a stale comment on the switch_mm() function.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/efi.h | 26 +++++++++++++-
> arch/arm64/include/asm/mmu_context.h | 51 +++++++++++++++++++--------
> arch/arm64/include/asm/ptrace.h | 2 ++
> arch/arm64/kernel/entry.S | 67 ++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/setup.c | 9 +++++
> arch/arm64/mm/context.c | 7 +++-
> 6 files changed, 146 insertions(+), 16 deletions(-)
[...]
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index ada08b5b036d..458773ac5ec9 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -21,6 +21,8 @@
>
> #include <uapi/asm/ptrace.h>
>
> +#define _PSR_PAN_BIT 22
[...]
> + .if \el != 0
> + tbnz x22, #_PSR_PAN_BIT, 1f // Skip re-enabling TTBR0 access if previously disabled
> + .endif
I really don't like the duplication of the #defines, just because tbnz
takes a bit number rather than a mask. I think for now we should follow
the status quo and use the immediate with a comment (we already do this
with PSR_I_BIT), but perhaps as a followup we should adjust the UAPI
headers to generate the PSR masks using shifts instead?
Not taken a proper look at the series yet, but this jumped out at me :)
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution
Date: Wed, 14 Sep 2016 17:45:11 +0100 [thread overview]
Message-ID: <20160914164511.GJ19622@arm.com> (raw)
In-Reply-To: <1473788797-10879-5-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 06:46:34PM +0100, Catalin Marinas wrote:
> When the TTBR0 PAN feature is enabled, the kernel entry points need to
> disable access to TTBR0_EL1. The PAN status of the interrupted context
> is stored as part of the saved pstate, reusing the PSR_PAN_BIT (22).
> Restoring access to TTBR0_PAN is done on exception return if returning
> to user or returning to a context where PAN was disabled.
>
> Context switching via switch_mm() must defer the update of TTBR0_EL1
> until a return to user or an explicit uaccess_enable() call.
>
> Special care needs to be taken for two cases where TTBR0_EL1 is set
> outside the normal kernel context switch operation: EFI run-time
> services (via efi_set_pgd) and CPU suspend (via cpu_(un)install_idmap).
> Code has been added to avoid deferred TTBR0_EL1 switching as in
> switch_mm() and restore the reserved TTBR0_EL1 when uninstalling the
> special TTBR0_EL1.
>
> This patch also removes a stale comment on the switch_mm() function.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/efi.h | 26 +++++++++++++-
> arch/arm64/include/asm/mmu_context.h | 51 +++++++++++++++++++--------
> arch/arm64/include/asm/ptrace.h | 2 ++
> arch/arm64/kernel/entry.S | 67 ++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/setup.c | 9 +++++
> arch/arm64/mm/context.c | 7 +++-
> 6 files changed, 146 insertions(+), 16 deletions(-)
[...]
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index ada08b5b036d..458773ac5ec9 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -21,6 +21,8 @@
>
> #include <uapi/asm/ptrace.h>
>
> +#define _PSR_PAN_BIT 22
[...]
> + .if \el != 0
> + tbnz x22, #_PSR_PAN_BIT, 1f // Skip re-enabling TTBR0 access if previously disabled
> + .endif
I really don't like the duplication of the #defines, just because tbnz
takes a bit number rather than a mask. I think for now we should follow
the status quo and use the immediate with a comment (we already do this
with PSR_I_BIT), but perhaps as a followup we should adjust the UAPI
headers to generate the PSR masks using shifts instead?
Not taken a proper look at the series yet, but this jumped out at me :)
Will
next prev parent reply other threads:[~2016-09-14 16:45 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 17:46 [kernel-hardening] [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 1/7] arm64: Factor out PAN enabling/disabling into separate uaccess_* macros Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-15 15:10 ` [kernel-hardening] " Mark Rutland
2016-09-15 15:10 ` Mark Rutland
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 2/7] arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-15 15:19 ` [kernel-hardening] " Mark Rutland
2016-09-15 15:19 ` Mark Rutland
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 3/7] arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1 Catalin Marinas
2016-09-13 17:46 ` [PATCH v3 3/7] arm64: Introduce uaccess_{disable, enable} " Catalin Marinas
2016-09-13 20:45 ` [kernel-hardening] Re: [PATCH v3 3/7] arm64: Introduce uaccess_{disable,enable} " Kees Cook
2016-09-13 20:45 ` Kees Cook
2016-09-14 8:52 ` [kernel-hardening] " Mark Rutland
2016-09-14 8:52 ` Mark Rutland
2016-09-14 16:27 ` [kernel-hardening] " Kees Cook
2016-09-14 16:27 ` Kees Cook
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-14 16:45 ` Will Deacon [this message]
2016-09-14 16:45 ` Will Deacon
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 5/7] arm64: Handle faults caused by inadvertent user access with PAN enabled Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-16 11:33 ` [kernel-hardening] " Mark Rutland
2016-09-16 11:33 ` Mark Rutland
2016-09-16 15:55 ` [kernel-hardening] " Catalin Marinas
2016-09-16 15:55 ` Catalin Marinas
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 6/7] arm64: xen: Enable user access before a privcmd hvc call Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-13 17:46 ` [kernel-hardening] [PATCH v3 7/7] arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN Catalin Marinas
2016-09-13 17:46 ` Catalin Marinas
2016-09-14 10:13 ` [kernel-hardening] Re: [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching Ard Biesheuvel
2016-09-14 10:13 ` Ard Biesheuvel
2016-09-14 10:27 ` [kernel-hardening] " Mark Rutland
2016-09-14 10:27 ` Mark Rutland
2016-09-14 10:30 ` [kernel-hardening] " Ard Biesheuvel
2016-09-14 10:30 ` Ard Biesheuvel
2016-09-14 10:36 ` [kernel-hardening] " Mark Rutland
2016-09-14 10:36 ` Mark Rutland
2016-09-14 10:48 ` [kernel-hardening] " Mark Rutland
2016-09-14 10:48 ` Mark Rutland
2016-09-14 20:54 ` [kernel-hardening] " David Brown
2016-09-14 20:54 ` David Brown
2016-09-15 9:52 ` Catalin Marinas
2016-09-15 9:52 ` Catalin Marinas
2016-09-15 16:20 ` [kernel-hardening] " Mark Rutland
2016-09-15 16:20 ` Mark Rutland
2016-09-15 16:41 ` [kernel-hardening] " Mark Rutland
2016-09-15 16:41 ` Mark Rutland
2016-09-29 22:44 ` [kernel-hardening] " Sami Tolvanen
2016-09-29 22:44 ` Sami Tolvanen
2016-09-30 18:42 ` Kees Cook
2016-09-30 18:42 ` Kees Cook
2016-10-27 14:54 ` Catalin Marinas
2016-10-27 14:54 ` Catalin Marinas
2016-10-27 21:23 ` Kees Cook
2016-10-27 21:23 ` Kees Cook
2016-10-14 21:44 ` Kees Cook
2016-10-14 21:44 ` Kees Cook
2016-10-15 14:35 ` [kernel-hardening] " Catalin Marinas
2016-10-15 14:35 ` Catalin Marinas
2016-10-16 2:04 ` [kernel-hardening] " Kees Cook
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=20160914164511.GJ19622@arm.com \
--to=will.deacon@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=takahiro.akashi@linaro.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.