From: Catalin Marinas <catalin.marinas@arm.com>
To: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: keescook@chromium.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/2] arm64: Support execute-only permissions with Enhanced PAN
Date: Tue, 17 Nov 2020 16:47:43 +0000 [thread overview]
Message-ID: <X7P+r/l3ewvaf1aV@trantor> (raw)
In-Reply-To: <20201113152023.102855-2-vladimir.murzin@arm.com>
On Fri, Nov 13, 2020 at 03:20:22PM +0000, Vladimir Murzin wrote:
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 4ff12a7..d1f68d2 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -113,8 +113,15 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
> #define pte_dirty(pte) (pte_sw_dirty(pte) || pte_hw_dirty(pte))
>
> #define pte_valid(pte) (!!(pte_val(pte) & PTE_VALID))
> -#define pte_valid_not_user(pte) \
> - ((pte_val(pte) & (PTE_VALID | PTE_USER)) == PTE_VALID)
> +#define pte_valid_not_user(pte) \
> +({ \
> + int __val; \
> + if (cpus_have_const_cap(ARM64_HAS_EPAN)) \
> + __val = (pte_val(pte) & (PTE_VALID | PTE_USER | PTE_UXN)) == (PTE_VALID | PTE_UXN); \
> + else \
> + __val = (pte_val(pte) & (PTE_VALID | PTE_USER)) == PTE_VALID; \
> + __val; \
Is it worth having the cap check here? I'd go with the PTE_VALID|PTE_UXN
check only.
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index dcc165b..2033e0b 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1602,6 +1602,13 @@ static void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused)
> }
> #endif /* CONFIG_ARM64_PAN */
>
> +#ifdef CONFIG_ARM64_EPAN
> +static void cpu_enable_epan(const struct arm64_cpu_capabilities *__unused)
> +{
> + sysreg_clear_set(sctlr_el1, 0, SCTLR_EL1_EPAN);
> +}
> +#endif /* CONFIG_ARM64_EPAN */
I checked the spec (2020 arch updates) and the EPAN bit is permitted to
be cached in the TLB. I think we get away with this because this
function is called before cnp is enabled. Maybe we should make it
explicit and move the CnP entry last with a comment.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-17 16:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 15:20 [RFC PATCH 0/2] arm64: Support Enhanced PAN Vladimir Murzin
2020-11-13 15:20 ` [RFC PATCH 1/2] arm64: Support execute-only permissions with " Vladimir Murzin
2020-11-17 16:47 ` Catalin Marinas [this message]
2020-11-18 12:37 ` Vladimir Murzin
2020-11-18 16:04 ` Catalin Marinas
2020-11-19 13:39 ` Vladimir Murzin
2020-11-13 15:20 ` [RFC PATCH 2/2] arm64: Expose EPAN support via HWCAPS2_EPAN Vladimir Murzin
2020-11-17 16:59 ` Catalin Marinas
2020-11-18 12:43 ` Vladimir Murzin
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=X7P+r/l3ewvaf1aV@trantor \
--to=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=vladimir.murzin@arm.com \
/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.