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

diff --git a/arch/parisc/include/asm/mman.h b/arch/parisc/include/asm/mman.h
new file mode 100644
index 000000000000..47c5a1991d10
--- /dev/null
+++ b/arch/parisc/include/asm/mman.h
@@ -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__ */
diff --git a/include/linux/mman.h b/include/linux/mman.h
index dc7048824be8..bcb201ab7a41 100644
--- a/include/linux/mman.h
+++ b/include/linux/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.
  *
diff --git a/kernel/sys.c b/kernel/sys.c
index f8e543f1e38a..8bb106a56b3a 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -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();
-- 
2.43.2

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

On Tue, Feb 27, 2024 at 11:53:59AM PST, Helge Deller wrote:
>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

Ping...Russell, Andrew, any thoughts on how this could move forward?


Thanks,
Zev