prctl call wrongly succeeds on HPPA?

DISCUSSION Sam James 3 participants 17 messages Oct 31, 2023 – Nov 19, 2023

Share & tools

Sam James

author

2023-10-31 04:34 UTC #0 lore raw

I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.

On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.

Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?

Reported to systemd at https://github.com/systemd/systemd/issues/29775.

thanks,
sam

Sam James

author

2023-11-03 12:54 UTC #1 lore raw

Quoted 10 lines · Sam James

I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?
Reported to systemd at https://github.com/systemd/systemd/issues/29775.

Lennart has made clear (and I don't think I disagree) that he considers this squarely a kernel bug.

Quoted 3 lines

thanks,
sam

Helge Deller

2023-11-10 20:02 UTC #2 lore raw

Quoted 3 lines · Sam James

Quoted 2 lines · Sam James
I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.

Is this still a problem?

Quoted 2 lines

Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.

For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...

Quoted 7 lines

Quoted 4 lines
Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?
Reported to systemd at https://github.com/systemd/systemd/issues/29775.
Lennart has made clear (and I don't think I disagree) that he considers this squarely a kernel bug.

I've read the various bug reports and looked at the kernel commits regarding, e.g.

commit b507808ebce23561d4ff8c2aa1fb949fe402bc61

Author: Joey Gouly <[email protected]>
Date:   Thu Jan 19 16:03:43 2023 +0000

mm: implement memory-deny-write-execute as a prctl

but what is prctl(PR_SET_MDWE, PR_MDWE*, 0, 0)... expected to return on parisc? EINVAL? ENOTSUP?

Helge

John David Anglin

2023-11-10 20:13 UTC #3 lore raw

Quoted 6 lines · Helge Deller

Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...

FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.

gdb still needs a fix in unwind code.

Dave

Signature · 1 line

John David Anglin  [email protected]

Helge Deller

2023-11-10 20:39 UTC #4 lore raw

Quoted 9 lines · John David Anglin

Quoted 6 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.

Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks? It would be easier if it would be a glibc dependency (for distribution maintainers)...

Quoted 1 line

gdb still needs a fix in unwind code.

Ok.

Helge

John David Anglin

2023-11-10 21:11 UTC #5 lore raw

Quoted 5 lines · Helge Deller

Quoted 4 lines · John David Anglin
Quoted 3 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?

Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.

Quoted 1 line

It would be easier if it would be a glibc dependency (for distribution maintainers)...

I'm not aware of any glibc dependency...

I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.

Dave

Signature · 1 line

John David Anglin  [email protected]

Sam James

author

2023-11-10 21:33 UTC #6 lore raw

Quoted 18 lines · John David Anglin

Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 3 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.

Quoted 5 lines

Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.

We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.

Quoted 2 lines

Dave

John David Anglin

2023-11-10 22:01 UTC #7 lore raw

Quoted 18 lines · Sam James

Quoted 16 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.

Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.

Dave

Signature · 1 line

John David Anglin  [email protected]

Sam James

author

2023-11-10 22:20 UTC #8 lore raw

Quoted 22 lines · John David Anglin

Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.

Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.

I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?

Let me know if missing something because the binutils configure stuff is a bit convoluted.

Quoted 2 lines

Dave

John David Anglin

2023-11-10 23:03 UTC #9 lore raw

Quoted 39 lines · Sam James

Quoted 22 lines · John David Anglin
Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.

Quoted 2 lines

I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?

You are right about both. We have in ld/configure.tgt:
if test "${ac_default_ld_warn_execstack}" = 2; then case "${targ}" in
# The HPPA port needs to support older kernels that

      # use executable stacks for signals and syscalls.
      # Many MIPS targets use executable stacks.
    hppa*-*-* | \
    mips*-*-*)
      ac_default_ld_warn_execstack=0
      ;;
    *)
      ;;
  esac
fi

We also may need:
#define elf_backend_default_execstack 0
in elf32-hppa.c at some point.

I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not. But I could be wrong 🙁

I'll try building binutils with gcc-14.

Dave

Signature · 1 line

John David Anglin  [email protected]

Helge Deller

2023-11-17 14:55 UTC #10 lore raw

Quoted 57 lines · John David Anglin

Quoted 39 lines · Sam James
Quoted 22 lines · John David Anglin
Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.
Quoted 2 lines
I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?
You are right about both. We have in ld/configure.tgt:
if test "${ac_default_ld_warn_execstack}" = 2; then
case "${targ}" in
# The HPPA port needs to support older kernels that
       # use executable stacks for signals and syscalls.
       # Many MIPS targets use executable stacks.
     hppa*-*-* | \
     mips*-*-*)
       ac_default_ld_warn_execstack=0
       ;;
     *)
       ;;
   esac
fi

Quoted 8 lines

We also may need:
#define elf_backend_default_execstack 0
in elf32-hppa.c at some point.
I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not. But I could be wrong 🙁
I'll try building binutils with gcc-14.

Did it worked?

Btw, I added a small section about executable stacks in the TODO section of the wiki:
https://parisc.wiki.kernel.org/index.php/TODO#executable_stack

Helge

John David Anglin

2023-11-17 15:42 UTC #11 lore raw

Quoted 62 lines · Helge Deller

Quoted 61 lines · John David Anglin
Quoted 39 lines · Sam James
Quoted 22 lines · John David Anglin
Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.
Quoted 2 lines
I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?
You are right about both. We have in ld/configure.tgt:
if test "${ac_default_ld_warn_execstack}" = 2; then case "${targ}" in
# The HPPA port needs to support older kernels that
       # use executable stacks for signals and syscalls.
       # Many MIPS targets use executable stacks.
     hppa*-*-* | \
     mips*-*-*)
       ac_default_ld_warn_execstack=0
       ;;
     *)
       ;;
   esac
fi
We also may need:
#define elf_backend_default_execstack 0
in elf32-hppa.c at some point.

Quoted 6 lines

Quoted 4 lines
I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not. But I could be wrong 🙁
I'll try building binutils with gcc-14.
Did it worked?

Build succeeds but there are about a dozen fails in ld testsuite which need investigation.

I got waylaid:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415

Jeff thinks the patch which I committed to gcc trunk to improve handling of REG+D addresses will fail: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637018.html

There have been many problems with this over the years but I would prefer to see what breaks with current implementation. It fixes python build and we no longer need to disable inlining of small functions. A lot of water has passed under the bridge since Jeff worked on the issue.

Quoted 4 lines

Btw, I added a small section about executable stacks in the TODO section of the wiki:
https://parisc.wiki.kernel.org/index.php/TODO#executable_stack

Dave

Signature · 1 line

John David Anglin  [email protected]

Sam James

author

2023-11-18 05:53 UTC #12 lore raw

Quoted 74 lines · John David Anglin

Quoted 62 lines · Helge Deller
Quoted 61 lines · John David Anglin
Quoted 39 lines · Sam James
Quoted 22 lines · John David Anglin
Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.
Quoted 2 lines
I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?
You are right about both. We have in ld/configure.tgt:
if test "${ac_default_ld_warn_execstack}" = 2; then case "${targ}" in
# The HPPA port needs to support older kernels that
       # use executable stacks for signals and syscalls.
       # Many MIPS targets use executable stacks.
     hppa*-*-* | \
     mips*-*-*)
       ac_default_ld_warn_execstack=0
       ;;
     *)
       ;;
   esac
fi
We also may need:
#define elf_backend_default_execstack 0
in elf32-hppa.c at some point.
Quoted 6 lines
Quoted 4 lines
I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not. But I could be wrong 🙁
I'll try building binutils with gcc-14.
Did it worked?
Build succeeds but there are about a dozen fails in ld testsuite which need investigation.
I got waylaid:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415

Quoted 6 lines

Jeff thinks the patch which I committed to gcc trunk to improve handling of REG+D addresses will fail: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637018.html
There have been many problems with this over the years but I would prefer to see what breaks with current implementation. It fixes python build and we no longer need to disable inlining of small functions. A lot of water has passed under the bridge since Jeff worked on the issue.

OK, I'll go ahead with testing then and let you know if there's any issue. I didn't want to start if it was going to be reverted shortly or something.

Am keen on seeing if I notice any differences with Python build time and runtime performance too...

Quoted 4 lines

Quoted 4 lines
Btw, I added a small section about executable stacks in the TODO section of the wiki:
https://parisc.wiki.kernel.org/index.php/TODO#executable_stack

Nice, thanks!

Quoted 2 lines

Dave

Sam James

author

2023-11-19 12:12 UTC #13 lore raw

In reply to Helge Deller

Quoted 62 lines · Helge Deller

Quoted 61 lines · John David Anglin
Quoted 39 lines · Sam James
Quoted 22 lines · John David Anglin
Quoted 21 lines · Sam James
Quoted 19 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 5 lines · Helge Deller
Quoted 2 lines
Quoted 2 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
FWIW, I recently changed gcc-14 to enable GNU stack notes and fixed a bug in the 32-bit PA 2.0 trampoline template. All execute stack tests in glibc now pass with gcc-14.
Yes, I saw your commits.
So, any code compiled with >= gcc-14 should be fine with non-writeable stacks?
Not exactly. An executable stack is still needed for nested functions. They are still called via a stack trampoline. The GNU stack note indicates whether an object needs an executable stack or not. These notes are collected by linker. The glibc loader determines whether to setup an executable stack or not.
Quoted 1 line
It would be easier if it would be a glibc dependency (for distribution maintainers)...
I'm not aware of any glibc dependency...
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think once gcc-14 becomes the default compiler, we will have to enable GNU stack notes in previous gcc versions. We will still have executable stacks until everything is rebuilt.
We will need to update that default in Binutils too, I think. That configure arg is working OK for me, but I did not try systemd yet.
Currently, there are no architecture dependencies in the ld --enable-warn-execstack and --enable-default-execstack configure options. The -z execstack and -z noexecstack ld options can override the GNU notes, or lack thereof. We may have to fix some assembly code. Maybe binutils should be built with --enable-warn-execstack once we switch to gcc-14. I don't think we want --enable-default-execstack after switching to gcc-14.
Are you sure? I just did some more digging now...
* It looks like targets can set elf_backend_default_execstack in
bfd/elf-*.c to override the default, see e.g. 81cd0a49c9e5f28c0fec391e449ea3272077c432 for cris.
* See acd65fa610df09a0954b8fecdadf546215263c5d where HPPA's default got changed.
* ld/configure.tgt still has some suppression for HPPA's default for
warnings.
Quoted 2 lines
I think we may need to, in due course, set elf_backend_default_execstack in bfd/elf32-hppa.c, and then drop those bits in ld/configure.tgt too?
You are right about both. We have in ld/configure.tgt:
if test "${ac_default_ld_warn_execstack}" = 2; then
case "${targ}" in
# The HPPA port needs to support older kernels that
       # use executable stacks for signals and syscalls.
       # Many MIPS targets use executable stacks.
     hppa*-*-* | \
     mips*-*-*)
       ac_default_ld_warn_execstack=0
       ;;
     *)
       ;;
   esac
fi
We also may need:
#define elf_backend_default_execstack 0
in elf32-hppa.c at some point.

Quoted 7 lines

Quoted 4 lines
I think when GNU stack notes are present, they determine whether the stack in an executable will be executable or not. But I could be wrong 🙁
I'll try building binutils with gcc-14.
Did it worked?

In addition to my other email: while I am doing GCC 14 test builds for Dave's patch, I am including the Binutils changes (just local hacks for now) to play with fixed stack notes too, so I will let you both know if there's any problems with that too.

Quoted 5 lines

Btw, I added a small section about executable stacks in the TODO section of the wiki:
https://parisc.wiki.kernel.org/index.php/TODO#executable_stack
Helge

Sam James

author

2023-11-10 20:14 UTC #14 lore raw

In reply to Helge Deller

Quoted 6 lines · Helge Deller

Quoted 3 lines · Sam James
Quoted 2 lines · Sam James
I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
Is this still a problem?

Yes. When I get time, I will play with Dave's changes to allow using non-exeuctable stacks, but for now, it is broken until I can test these (thanks dave for working on that, and helge for the kernel side).

Quoted 8 lines

Quoted 3 lines
Quoted 3 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...

I don't remember which kernel version either.. I think it was last year that you finished off all the DSO bits.

I had to configure binutils with --enable-default-execstack=no for it to work in addition to Dave's GCC patches. But I did not test systemd yet...

(sorry, I know this is equally vague.)

Quoted 10 lines

Quoted 7 lines
Quoted 4 lines
Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?
Reported to systemd at https://github.com/systemd/systemd/issues/29775.
Lennart has made clear (and I don't think I disagree) that he considers this squarely a kernel bug.
I've read the various bug reports and looked at the kernel commits regarding, e.g.

Quoted 8 lines

commit b507808ebce23561d4ff8c2aa1fb949fe402bc61
Author: Joey Gouly <[email protected]>
Date:   Thu Jan 19 16:03:43 2023 +0000
mm: implement memory-deny-write-execute as a prctl
but what is prctl(PR_SET_MDWE, PR_MDWE*, 0, 0)... expected to return on parisc? EINVAL? ENOTSUP?

Maybe we can ask Joey or the ARM people what they expect the semantics to be.

Quoted 2 lines

Helge

Helge Deller

2023-11-10 20:25 UTC #15 lore raw

* Sam James <[email protected]>:

Quoted 18 lines

Quoted 6 lines · Helge Deller
Quoted 3 lines · Sam James
Quoted 2 lines · Sam James
I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
Is this still a problem?
Yes. When I get time, I will play with Dave's changes to allow using non-exeuctable stacks, but for now, it is broken until I can test these (thanks dave for working on that, and helge for the kernel side).
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.

Quoted 7 lines

Quoted 4 lines
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
I don't remember which kernel version either.. I think it was last year that you finished off all the DSO bits.

Kernel 5.18+ should be OK:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df24e1783e6e0eb3dc0e3ba5a8df3bb0cc537408

Quoted 19 lines

I had to configure binutils with --enable-default-execstack=no for it to work in addition to Dave's GCC patches. But I did not test systemd yet...
(sorry, I know this is equally vague.)
Quoted 14 lines
Quoted 7 lines
Quoted 4 lines
Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?
Reported to systemd at https://github.com/systemd/systemd/issues/29775.
Lennart has made clear (and I don't think I disagree) that he considers this squarely a kernel bug.
I've read the various bug reports and looked at the kernel commits regarding, e.g.
commit b507808ebce23561d4ff8c2aa1fb949fe402bc61
Author: Joey Gouly <[email protected]>
Date:   Thu Jan 19 16:03:43 2023 +0000

Quoted 7 lines

Quoted 4 lines
mm: implement memory-deny-write-execute as a prctl
but what is prctl(PR_SET_MDWE, PR_MDWE*, 0, 0)... expected to return on parisc? EINVAL? ENOTSUP?
Maybe we can ask Joey or the ARM people what they expect the semantics to be.

Looking at https://fossies.org/linux/systemd/src/core/execute.c
1636

 1637         /* use prctl() if kernel supports it (6.3) */
 1638         r = prctl(PR_SET_MDWE, PR_MDWE_REFUSE_EXEC_GAIN, 0, 0, 0);
 1639         if (r == 0) {

1640 log_unit_debug(u, "Enabled MemoryDenyWriteExecute= with PR_SET_MDWE");
1641 return 0;
1642 }
1643 if (r < 0 && errno != EINVAL)
1644 return log_unit_debug_errno(u, errno, "Failed to enable MemoryDenyWriteExecute= with PR_SET_MDWE: %m");
1645 /* else use seccomp */
1646 log_unit_debug(u, "Kernel doesn't support PR_SET_MDWE: falling back to seccomp");
1647
1648 if (skip_seccomp_unavailable(u, "MemoryDenyWriteExecute="))
1649 return 0;
1650
1651 return seccomp_memory_deny_write_execute();
1652 }

it seems this patch/hack might at least not report success:

kernel/sys.c +4 -0

index 420d9cb9cc8e..fe4f2162457c 100644
@@ -2384,6 +2384,10 @@ static inline int prctl_set_mdwe(unsigned long bits, unsigned long arg3,
 {
 	unsigned long current_bits;
 
+	/* parisc still needs a writeable stack for older glibc versions */
+	if (IS_ENABLED(CONFIG_PARISC))
+		return -EINVAL;
+
 	if (arg3 || arg4 || arg5)
 		return -EINVAL;

A test would be good though, esp. since I don't know what the seccomp() functions are doing then.

Helge

Helge Deller

2023-11-10 20:32 UTC #16 lore raw

Quoted 94 lines · Helge Deller

* Sam James <[email protected]>:
Quoted 18 lines
Quoted 6 lines · Helge Deller
Quoted 3 lines · Sam James
Quoted 2 lines · Sam James
I recently hit an issue with systemd-254 which tries to use the new prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
Is this still a problem?
Yes. When I get time, I will play with Dave's changes to allow using non-exeuctable stacks, but for now, it is broken until I can test these (thanks dave for working on that, and helge for the kernel side).
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
On HPPA, we still need executable stacks, so this option doesn't work and leads to a segfault on boot.
Quoted 7 lines
Quoted 4 lines
For kernel we don't need it any longer.
But there might be dependencies on glibc version and/or combination. So, I've currently lost overview if we still need executable stacks...
I don't remember which kernel version either.. I think it was last year that you finished off all the DSO bits.
Kernel 5.18+ should be OK:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df24e1783e6e0eb3dc0e3ba5a8df3bb0cc537408
Quoted 19 lines
I had to configure binutils with --enable-default-execstack=no for it to work in addition to Dave's GCC patches. But I did not test systemd yet...
(sorry, I know this is equally vague.)
Quoted 14 lines
Quoted 7 lines
Quoted 4 lines
Should this call be succeeeding on HPPA, or should we reject it for now until we have things wired up?
Reported to systemd at https://github.com/systemd/systemd/issues/29775.
Lennart has made clear (and I don't think I disagree) that he considers this squarely a kernel bug.
I've read the various bug reports and looked at the kernel commits regarding, e.g.
commit b507808ebce23561d4ff8c2aa1fb949fe402bc61
Author: Joey Gouly <[email protected]>
Date:   Thu Jan 19 16:03:43 2023 +0000
Quoted 7 lines
Quoted 4 lines
mm: implement memory-deny-write-execute as a prctl
but what is prctl(PR_SET_MDWE, PR_MDWE*, 0, 0)... expected to return on parisc? EINVAL? ENOTSUP?
Maybe we can ask Joey or the ARM people what they expect the semantics to be.
Looking at https://fossies.org/linux/systemd/src/core/execute.c
1636
  1637         /* use prctl() if kernel supports it (6.3) */
  1638         r = prctl(PR_SET_MDWE, PR_MDWE_REFUSE_EXEC_GAIN, 0, 0, 0);
  1639         if (r == 0) {
1640 log_unit_debug(u, "Enabled MemoryDenyWriteExecute= with PR_SET_MDWE");
1641 return 0;
1642 }
1643 if (r < 0 && errno != EINVAL)
1644 return log_unit_debug_errno(u, errno, "Failed to enable MemoryDenyWriteExecute= with PR_SET_MDWE: %m");
1645 /* else use seccomp */
1646 log_unit_debug(u, "Kernel doesn't support PR_SET_MDWE: falling back to seccomp");
1647
1648 if (skip_seccomp_unavailable(u, "MemoryDenyWriteExecute="))
1649 return 0;
1650
1651 return seccomp_memory_deny_write_execute();
1652 }
it seems this patch/hack might at least not report success:
kernel/sys.c +4 -0
index 420d9cb9cc8e..fe4f2162457c 100644
@@ -2384,6 +2384,10 @@ static inline int prctl_set_mdwe(unsigned long bits, unsigned long arg3,
  {
  	unsigned long current_bits;
 
+	/* parisc still needs a writeable stack for older glibc versions */
+	if (IS_ENABLED(CONFIG_PARISC))
+		return -EINVAL;
+
  	if (arg3 || arg4 || arg5)
  		return -EINVAL;
 

Quoted 2 lines

A test would be good though, esp. since I don't know what the seccomp() functions are doing then.

actually, I think we should return any error code other than EINVAL. See line 1643 above, if we return e.g. -EACCES, systemd should give up.

Helge