Re: [PATCH 0/4] MDWE without inheritance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8.5.2023 17.10, Catalin Marinas wrote:
I think we should keep the original behaviour of systemd here, otherwise
they won't transition to the new interface and keep using the SECCOMP
BPF approach (which, in addition, prevents glibc from setting PROT_BTI
on an already executable mapping).

Systemd has transitioned to prctl(PR_SET_MDWE) method since release of v253, so the original behaviour definitely should be kept.

To me MDWE is not about preventing JITs but rather ensuring buggy
programs don't end up with WX mappings. We ended up this way because of
the SECCOMP BPF limitations (just guessing, I haven't been involved in
its design). With a no-inherit MDWE, one can introduce an additional
policy for systemd. It would be a sysadmin decision which one to enable
and maybe current (inherit) MDWE will disappear in time.

There could be a new setting for this, like MemoryDenyWriteExecute=no-inherit. I'd only use it for those special cases where MemoryDenyWriteExecute=yes can't be used.

x86 has protection keys and arm64 will soon have permission overlays
that allow user-space to toggle between RX and RW (Joey is looking at
the arm64 support). I'm not sure how we'll end up implemented this on
arm64 (and haven't looked at x86) but I have a suspicion MDWE will get
in the way as the base page table permission will probably need
PROT_WRITE|PROT_EXEC.

Wouldn't those features defeat any gains from MDWE? The features probably should be forbidden with MemoryDenyWriteExecute=yes.

-Topi





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux