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
