Re: [PATCH] S390: Enable static PIE

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella:

> On 02/05/2022 06:13, Florian Weimer via Libc-alpha wrote:
>> * Stefan Liebler via Libc-alpha:
>> 
>>> This commit enables static PIE on 64bit.  On 31bit, static PIE is
>>> not supported.
>>>
>>> - kernel (the mentioned links to the commits belong to 5.19 merge window):
>>>   - "s390/mmap: increase stack/mmap gap to 128MB"
>>>     https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=f2f47d0ef72c30622e62471903ea19446ea79ee2
>>>   - "s390/vdso: move vdso mapping to its own function"
>>>     https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=57761da4dc5cd60bed2c81ba0edb7495c3c740b8
>>>   - "s390/vdso: map vdso above stack"
>>>     https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=9e37a2e8546f9e48ea76c839116fa5174d14e033
>>>   - "s390/vdso: add vdso randomization"
>>>     https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=41cd81abafdc4e58a93fcb677712a76885e3ca25
>>>   (We can't test the kernel of the target system)
>>>   Otherwise if /proc/sys/kernel/randomize_va_space is turned off (0),
>>>   static PIE executables like ldconfig will crash.  While startup sbrk is
>>>   used to enlarge the HEAP.  Unfortunately the underlying brk syscall fails
>>>   as there is not enough space after the HEAP.  Then the address of the TLS
>>>   image is invalid and the following memcpy in __libc_setup_tls() leads
>>>   to a segfault.
>>>   If /proc/sys/kernel/randomize_va_space is activated (default: 2), there
>>>   is enough space after HEAP.
>> 
>> I'll work an early allocator that does not use the TCB and which should
>> avoid the sbrk crash.  Will that be sufficient to enable static PIE
>> binaries to run on unchanged kernels?
>> 
>> Otherwise I fear that we end up in a world of pain if we turn ldconfig
>> into a static PIE binary. 8-(
>
>
> I agree that ideally it should not rely a patched kernel to overcome the
> glibc issue of handling sbrk call failures and having a working loader
> allocator that work regardless of kernel version is the best approach. 
>
> As I put on weekly call, I would prefer to make it only use mmap as
> for simplicity. 

Getting mmap to work is actually the hard part due to six-argument
system call.  Trying sbrk first does not add much complexity.  I posted
my series:

  Linux: Fall back to mmap if early sbrk fails
  <https://sourceware.org/pipermail/libc-alpha/2022-May/138331.html>

Stefan, I would appreciate if you could check that the kernel fixes are
not strictly required anymore with these changes.

Thanks,
Florian