[PATCH v8 42/43] mm: add arch hook to validate mmap() prot flags

[Catalin Marinas]

On Wed, Mar 13, 2024 at 12:45:22PM +0100, Ard Biesheuvel wrote:
> On Wed, 13 Mar 2024 at 11:47, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > However, I've been looking through specs and realised that SCTLR_ELx.WXN
> > is RES0 when the permission indirection is enabled (FEAT_PIE from the
> > 2022 specs, hopefully you have access to it).
> 
> The latest public version of the ARM ARM does not cover FEAT_PIE at all.

According to Mark R, the next version should be out soon. The xml
tarball for the 2022 extensions doesn't have any new text for
SCTLR_ELx.WXN field either. I could only find it in the engineering spec
which isn't public:

  When Stage1 Base Permissions uses the Indirect Permission Scheme,
  SCTLR_ELx.WXN has no effect and is RES 0.

> > And while apparently WXN
> > gets better as it allows separate EL0/EL1 controls, it seems to only
> > apply when the base permission is RWX and the XN is toggled based on the
> > overlay permission (pkeys which Joey is working on). So it looks like
> > what the architects had in mind is optimising RW/RX switching via
> > overlays (no syscalls) but keeping the base permission RWX. The
> > traditional WXN hardening via SCTLR_EL1 disappeared.
> >
> > (adding Joey to the thread, he contributed the PIE support)
> 
> PIE sounds useful to implement things like JITs in user space, where
> you want a certain mapping to transition to RW while all other CPUs
> retain RX access concurrently.
> 
> WXN is intended to be static, where a single bit sets the system-wide
> policy for all kernel and user space code.

I agree. I guess no-one used the current WXN and the architects decided
to deprecate it.

> It's rather unfortunate that FEAT_PIE relies on RWX mappings and
> therefore needs to deprecate WXN entirely. It would have been nice to
> have something like this for the kernel, which never has a need for
> RWX mappings or transitioning mappings between RX and RW like that,
> and so overlays don't seem to be a great fit.

Indeed. It looks more of a risk to somehow use WXN in the kernel in
combination with overlays because of the RWX permission.

> I looked into this a bit more, and MDWE is a bit stricter than WXN,
> and therefore less suitable for enabling system-wide. It disallows
> adding executable permissions entirely, as well as adding write
> permissions to a mapping that is already executable. WXN just
> disallows setting both at the same time.

With MDWE, we tried to copy the semantics of the BPF variant. It allows
mmap(PROT_EXEC) but not mrpotect(PROT_EXEC). But I agree, it's slightly
different than your proposed WXN.

-- 
Catalin