Re: [PATCH] S390: Enable static PIE

[Stefan Liebler <stli@linux.ibm.com>]

On 02/05/2022 21:18, Florian Weimer wrote:
> * 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
> 
Hi Florian and Adhemerval,

I've just build glibc-HEAD and run the testsuite with
/proc/sys/kernel/randomize_va_space = 0. => Recognized fails as srbk failed.

Then I've build with Florian's patch series on top. I don't see any
testsuite fails. Furthermore I've debbugged a static testcase into
_dl_early_allocate => mmap was used as result and previous was equal.

With Florian's patch series also applied, static PIE binaries also run
on an unchanged kernel.

Thanks,
Stefan