prctl call wrongly succeeds on HPPA?

prctl call wrongly succeeds on HPPA?

[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.

thanks,
sam

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

Sam James <sam@gentoo.org> writes:

> 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.

>
> thanks,
> sam

Re: prctl call wrongly succeeds on HPPA?

[Helge Deller]

On 11/3/23 13:53, Sam James wrote:
> Sam James <sam@gentoo.org> writes:
>> 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?

>> 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...

>> 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 <joey.gouly@arm.com>
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

Re: prctl call wrongly succeeds on HPPA?

[John David Anglin]

On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>> 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

-- 
John David Anglin  dave.anglin@bell.net

Re: prctl call wrongly succeeds on HPPA?

[Helge Deller]

On 11/10/23 21:12, John David Anglin wrote:
> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>> 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)...

> gdb still needs a fix in unwind code.

Ok.

Helge

Re: prctl call wrongly succeeds on HPPA?

[John David Anglin]

On 2023-11-10 3:38 p.m., Helge Deller wrote:
> On 11/10/23 21:12, John David Anglin wrote:
>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>> 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.
> 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

-- 
John David Anglin  dave.anglin@bell.net

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

John David Anglin <dave.anglin@bell.net> writes:

> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>> On 11/10/23 21:12, John David Anglin wrote:
>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>> 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.
>> 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.

>
> Dave

Re: prctl call wrongly succeeds on HPPA?

[John David Anglin]

On 2023-11-10 4:32 p.m., Sam James wrote:
> John David Anglin <dave.anglin@bell.net> writes:
>
>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>> On 11/10/23 21:12, John David Anglin wrote:
>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>> 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.
>>> 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

-- 
John David Anglin  dave.anglin@bell.net

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

John David Anglin <dave.anglin@bell.net> writes:

> On 2023-11-10 4:32 p.m., Sam James wrote:
>> John David Anglin <dave.anglin@bell.net> writes:
>>
>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>> 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.
>>>> 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.

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.

>
> Dave

Re: prctl call wrongly succeeds on HPPA?

[John David Anglin]

On 2023-11-10 5:16 p.m., Sam James wrote:
> John David Anglin <dave.anglin@bell.net> writes:
>
>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>> John David Anglin <dave.anglin@bell.net> writes:
>>>
>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>> 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.
>>>>> 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.
> 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?
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

-- 
John David Anglin  dave.anglin@bell.net

Re: prctl call wrongly succeeds on HPPA?

[Helge Deller]

On 11/11/23 00:02, John David Anglin wrote:
> On 2023-11-10 5:16 p.m., Sam James wrote:
>> John David Anglin <dave.anglin@bell.net> writes:
>>
>>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>>> John David Anglin <dave.anglin@bell.net> writes:
>>>>
>>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>>> 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.
>>>>>> 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.
>> 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?
> 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.

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

Re: prctl call wrongly succeeds on HPPA?

[John David Anglin]

On 2023-11-17 9:55 a.m., Helge Deller wrote:
> On 11/11/23 00:02, John David Anglin wrote:
>> On 2023-11-10 5:16 p.m., Sam James wrote:
>>> John David Anglin <dave.anglin@bell.net> writes:
>>>
>>>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>>>> John David Anglin <dave.anglin@bell.net> writes:
>>>>>
>>>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>>>> 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.
>>>>>>> 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.
>>> 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?
>> 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.
>
> 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.
>
> 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

-- 
John David Anglin  dave.anglin@bell.net

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

John David Anglin <dave.anglin@bell.net> writes:

> On 2023-11-17 9:55 a.m., Helge Deller wrote:
>> On 11/11/23 00:02, John David Anglin wrote:
>>> On 2023-11-10 5:16 p.m., Sam James wrote:
>>>> John David Anglin <dave.anglin@bell.net> writes:
>>>>
>>>>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>>>>> John David Anglin <dave.anglin@bell.net> writes:
>>>>>>
>>>>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>>>>> 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.
>>>>>>>> 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.
>>>> 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?
>>> 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.
>>
>> 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.

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...

>>
>> 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!

>
> Dave

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

Helge Deller <deller@gmx.de> writes:

> On 11/11/23 00:02, John David Anglin wrote:
>> On 2023-11-10 5:16 p.m., Sam James wrote:
>>> John David Anglin <dave.anglin@bell.net> writes:
>>>
>>>> On 2023-11-10 4:32 p.m., Sam James wrote:
>>>>> John David Anglin <dave.anglin@bell.net> writes:
>>>>>
>>>>>> On 2023-11-10 3:38 p.m., Helge Deller wrote:
>>>>>>> On 11/10/23 21:12, John David Anglin wrote:
>>>>>>>> On 2023-11-10 3:01 p.m., Helge Deller wrote:
>>>>>>>>>>> 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.
>>>>>>> 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.
>>> 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?
>> 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.
>
> 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.

> 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

Re: prctl call wrongly succeeds on HPPA?

[Sam James]

Helge Deller <deller@gmx.de> writes:

> On 11/3/23 13:53, Sam James wrote:
>> Sam James <sam@gentoo.org> writes:
>>> 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).

>
>>> 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.)

>>> 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 <joey.gouly@arm.com>
> 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.

>
> Helge

Re: prctl call wrongly succeeds on HPPA?

[Helge Deller]

* Sam James <sam@gentoo.org>:
> 
> Helge Deller <deller@gmx.de> writes:
> 
> > On 11/3/23 13:53, Sam James wrote:
> >> Sam James <sam@gentoo.org> writes:
> >>> 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).
> 
> >
> >>> 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.

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

> 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.)
> 
> >>> 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 <joey.gouly@arm.com>
> > 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.

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:

diff --git a/kernel/sys.c b/kernel/sys.c
index 420d9cb9cc8e..fe4f2162457c 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -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

Re: prctl call wrongly succeeds on HPPA?

[Helge Deller]

On 11/10/23 21:25, Helge Deller wrote:
> * Sam James <sam@gentoo.org>:
>>
>> Helge Deller <deller@gmx.de> writes:
>>
>>> On 11/3/23 13:53, Sam James wrote:
>>>> Sam James <sam@gentoo.org> writes:
>>>>> 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).
>>
>>>
>>>>> 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.
>
> Kernel 5.18+ should be OK:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df24e1783e6e0eb3dc0e3ba5a8df3bb0cc537408
>
>> 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.)
>>
>>>>> 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 <joey.gouly@arm.com>
>>> 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.
>
> 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:
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 420d9cb9cc8e..fe4f2162457c 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -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.

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