Re: [PATCH 2/2] arm64: Introduce HWCAPS2_EXECONLY

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Dec 08, 2020 at 04:36:16PM +0000, Dave P Martin wrote:
> 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)]:

I don't think you did ;).

> 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.

We could expose HWCAP2_EPAN which implies exec-only but I find it weird
(we had the precedent of HWCAP_LPAE on arm32 which meant 64-bit atomics
available). You can look at this as an architecture feature allowing
user execute-only permissions.

> 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.

We already made this decision when we first introduced the execute-only
permission. We've had it for a while and haven't heard of any instance
of PROT_EXEC-only mapping expecting PROT_READ. The reason we reverted
that change was that it was invalidating the PAN kernel protection. So
I'm not concerned about changing the ABI but what I'd like is to inform
the user that exec-only is available, in case it wants to do something
with it.

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

See above and commit cab15ce604e5 ("arm64: Introduce execute-only page
access permissions") from 2016.

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

If you don't like HWCAP, we could use a bit in AT_FLAGS (they are all
currently 0). But, arguably, exec-only is a property that the hardware
offers, though indirectly. I agree you can look at this either way.

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

I think x86 with protection keys can offer a similar mechanism but I
haven't checked.

-- 
Catalin

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