[RESEND,1/2] prctl: Generalize PR_SET_MDWE support check to be per-arch
Commit Message
There exist systems other than PARISC where MDWE may not be feasible
to support; rather than cluttering up the generic code with additional
arch-specific logic let's add a generic function for checking MDWE
support and allow each arch to override it as needed.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Cc: <stable@vger.kernel.org> # v6.3+
---
arch/parisc/include/asm/mman.h | 14 ++++++++++++++
include/linux/mman.h | 8 ++++++++
kernel/sys.c | 7 +++++--
3 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 arch/parisc/include/asm/mman.h
Comments
On Mon, Feb 26, 2024 at 05:35:41PM -0800, Zev Weiss wrote:
> There exist systems other than PARISC where MDWE may not be feasible
> to support; rather than cluttering up the generic code with additional
> arch-specific logic let's add a generic function for checking MDWE
> support and allow each arch to override it as needed.
>
> Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
> Cc: <stable@vger.kernel.org> # v6.3+
PA-RISC folk need to ack/review-by this patch. Alternatively, it needs
to be restructured to add the arch_memory_deny_write_exec_supported()
override without touching the PA-RISC code, which then makes the Arm
patch independent of the status of the PA-RISC patch. That will allow
the Arm issue to be solved even if an ack is not forthcoming for the
PA-RISC parts.
Alternatively, I wonder whether akpm would be willing to pick up this
patch set as-is.
On 2/27/24 11:24, Russell King (Oracle) wrote:
> On Mon, Feb 26, 2024 at 05:35:41PM -0800, Zev Weiss wrote:
>> There exist systems other than PARISC where MDWE may not be feasible
>> to support; rather than cluttering up the generic code with additional
>> arch-specific logic let's add a generic function for checking MDWE
>> support and allow each arch to override it as needed.
>>
>> Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
>> Cc: <stable@vger.kernel.org> # v6.3+
>
> PA-RISC folk need to ack/review-by this patch.
I'm fine with patch 1/2:
Acked-by: Helge Deller <deller@gmx.de> # parisc
> Alternatively, it needs
> to be restructured to add the arch_memory_deny_write_exec_supported()
> override without touching the PA-RISC code, which then makes the Arm
> patch independent of the status of the PA-RISC patch. That will allow
> the Arm issue to be solved even if an ack is not forthcoming for the
> PA-RISC parts.
>> Alternatively, I wonder whether akpm would be willing to pick up this
> patch set as-is.
I have no preference, but I think both patches should be pushed
together via arm tree or akpm.
Helge
new file mode 100644
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_MMAN_H__
+#define __ASM_MMAN_H__
+
+#include <uapi/asm/mman.h>
+
+/* PARISC cannot allow mdwe as it needs writable stacks */
+static inline bool arch_memory_deny_write_exec_supported(void)
+{
+ return false;
+}
+#define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported
+
+#endif /* __ASM_MMAN_H__ */
@@ -162,6 +162,14 @@ calc_vm_flag_bits(unsigned long flags)
unsigned long vm_commit_limit(void);
+#ifndef arch_memory_deny_write_exec_supported
+static inline bool arch_memory_deny_write_exec_supported(void)
+{
+ return true;
+}
+#define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported
+#endif
+
/*
* Denies creating a writable executable mapping or gaining executable permissions.
*
@@ -2408,8 +2408,11 @@ static inline int prctl_set_mdwe(unsigned long bits, unsigned long arg3,
if (bits & PR_MDWE_NO_INHERIT && !(bits & PR_MDWE_REFUSE_EXEC_GAIN))
return -EINVAL;
- /* PARISC cannot allow mdwe as it needs writable stacks */
- if (IS_ENABLED(CONFIG_PARISC))
+ /*
+ * EOPNOTSUPP might be more appropriate here in principle, but
+ * existing userspace depends on EINVAL specifically.
+ */
+ if (!arch_memory_deny_write_exec_supported())
return -EINVAL;
current_bits = get_current_mdwe();