All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: catalin.marinas@arm.com, keescook@chromium.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64: Introduce HWCAPS2_EXECONLY
Date: Tue, 8 Dec 2020 16:36:16 +0000	[thread overview]
Message-ID: <20201208163614.GS6882@arm.com> (raw)
In-Reply-To: <20201119133953.15585-3-vladimir.murzin@arm.com>

On Thu, Nov 19, 2020 at 01:39:53PM +0000, Vladimir Murzin wrote:
> With EPAN supported it might be handy to user know that PROT_EXEC
> gives execute-only permission, so advertise it via HWCAPS2_EXECONLY
> 
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  arch/arm64/include/asm/hwcap.h      | 1 +
>  arch/arm64/include/asm/sysreg.h     | 1 +
>  arch/arm64/include/uapi/asm/hwcap.h | 1 +
>  arch/arm64/kernel/cpufeature.c      | 3 +++
>  arch/arm64/kernel/cpuinfo.c         | 1 +
>  5 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> index 9a5498c..5ee5bce 100644
> --- a/arch/arm64/include/asm/hwcap.h
> +++ b/arch/arm64/include/asm/hwcap.h
> @@ -105,6 +105,7 @@
>  #define KERNEL_HWCAP_RNG		__khwcap2_feature(RNG)
>  #define KERNEL_HWCAP_BTI		__khwcap2_feature(BTI)
>  #define KERNEL_HWCAP_MTE		__khwcap2_feature(MTE)
> +#define KERNEL_HWCAP_EXECONLY		__khwcap2_feature(EXECONLY)

Should this definitely be an hwcap?

[Apologies if I already made this comment, but if I did I can't find a
record of it, so here it is again (or not)]:

This seems to have the wrong semantics for hwcaps: it's not a (purely) a
property of the hardware, not an arch-specific concept, and old code
that doesn't know about this flag may not work properly when the flag
is set.

Software that requires that any memory mapped without PROT_READ is
readable would be nonportable according to POSIX, but nonportable
doesn't mean not correct; it just means that POSIX doesn't gurarantee
that it works everywhere.


So:

1) Is true execute-only memory an ABI break that we care about, and do
we need an explicit opt-in?

2) Otherwise, is there another more suitable and less arch-specific
mechanism that could be used?  (Maybe AT_FLAGS or similar?)

This issue may have come up on other arches.  I've not gone digging.

Cheers
---Dave

[...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-12-08 16:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 13:39 [PATCH 0/2] arm64: Support Enhanced PAN Vladimir Murzin
2020-11-19 13:39 ` [PATCH 1/2] arm64: Support execute-only permissions with " Vladimir Murzin
2020-11-19 18:22   ` Catalin Marinas
2020-11-19 18:52   ` Dave Martin
2020-11-27 18:31     ` Catalin Marinas
2020-12-02 18:23   ` Catalin Marinas
2020-12-08 11:41     ` Vladimir Murzin
2020-11-19 13:39 ` [PATCH 2/2] arm64: Introduce HWCAPS2_EXECONLY Vladimir Murzin
2020-12-08 16:36   ` Dave Martin [this message]
2020-12-08 17:34     ` 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=20201208163614.GS6882@arm.com \
    --to=dave.martin@arm.com \
    --cc=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.