From: Sam James <sam@gentoo.org>
To: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>,
Sam James <sam@gentoo.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>
Subject: Re: prctl call wrongly succeeds on HPPA?
Date: Sun, 19 Nov 2023 12:11:36 +0000 [thread overview]
Message-ID: <87ttpij61m.fsf@gentoo.org> (raw)
In-Reply-To: <0cec0dfb-7a13-41fb-8498-3844102d18a5@gmx.de>
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
next prev parent reply other threads:[~2023-11-19 12:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 4:32 prctl call wrongly succeeds on HPPA? Sam James
2023-11-03 12:53 ` Sam James
2023-11-10 20:01 ` Helge Deller
2023-11-10 20:12 ` John David Anglin
2023-11-10 20:38 ` Helge Deller
2023-11-10 21:08 ` John David Anglin
2023-11-10 21:32 ` Sam James
2023-11-10 22:00 ` John David Anglin
2023-11-10 22:16 ` Sam James
2023-11-10 23:02 ` John David Anglin
2023-11-17 14:55 ` Helge Deller
2023-11-17 15:41 ` John David Anglin
2023-11-18 5:52 ` Sam James
2023-11-19 12:11 ` Sam James [this message]
2023-11-10 20:12 ` Sam James
2023-11-10 20:25 ` Helge Deller
2023-11-10 20:31 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttpij61m.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=dave.anglin@bell.net \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).