From: Stefan Liebler <stli@linux.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v3] malloc: Remove bin scanning from memalign (bug 30723)
Date: Thu, 21 Sep 2023 15:05:04 +0200 [thread overview]
Message-ID: <8c8dba8c-0e22-cd93-48e8-27482b3bc157@linux.ibm.com> (raw)
In-Reply-To: <87fs3850as.fsf@oldenburg.str.redhat.com>
On 20.09.23 17:31, Florian Weimer wrote:
> * Stefan Liebler:
>
>>> Does your kernel have a fix for the early sbrk failure? I suspect what
>>> happens is that we fall over to mmap from sbrk, making the heap
>>> non-contiguous.
>>>
>>> The sbrk failure should be visible under strace.
>>>
>> Yes, strace shows mmap with randomize_va_space=0:
>> brk(NULL) = 0x3fff7fb2000
>> brk(0x3fff7fd3000) = 0x3fff7fd3000
>> brk(0x3fff7ff7000) = 0x3fff7fd3000
>> mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> 0) = 0x3fff7b00000
>
> Ahh, looks like we can get 4 KiB or maybe 8 KiB of heap from the kernel.
> That's why we didn't crash before in early startup. It looks like a
> another ASLR layout issue, different from the problem that broke static
> PIE.
>
> Not sure what we can do about this. Obviously, we'd prefer if the test
> suite ran with a more production-like malloc configuration.
>
>> write(1, "error: tst-memalign-2.c:158: not"..., 54error:
>> tst-memalign-2.c:158: not true: count > LN / 2
>> ) = 54
>>
>> Note that there is this previous mmap-event before set_tid_address-syscall:
>> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
>> = 0x3fff7ff7000
>
> This is the ld.so minimal malloc, it doesn't use sbrk.
>
> Thanks,
> Florian
>
Just as summary:
Without randomization (/proc/sys/kernel/randomize_va_space == 0):
3fff7c00000-3fff7e1d000 libc.so
3fff7f00000-3fff7f08000 tst-memalign-2
3fff7f80000-3fff7fb4000 ld.so
3fff7fb4000-3fff7fd5000 [heap]
3fff7ff7000-3fff7ffb000 ld.so-minimal-malloc
3fffffda000-3ffffffb000 [stack]
=> brk tries to extend heap and fails due to "ld.so-minimal-malloc".
Then mmap is used which leads to the test-fail.
If I remember correctly, the kernel-guys mentioned - while static-PIE
issue - that the heap is "always" located after the main-program. The
glibc test-cases are run by executing ld.so directly.
But if randomization (/proc/sys/kernel/randomize_va_space == 2) is
turned on:
2aa019d8000-2aa01a44000 [heap]
3ff80f00000-3ff8111d000 libc.so
3ff81280000-3ff81288000 tst-memalign-2
3ff81301000-3ff81334000 ld.so
3ff81377000-3ff8137b000 ld.so-minimal-malloc
3ffd6ada000-3ffd6afb000 [stack]
As comparison "cat /proc/self/maps" with randomization:
2aa22780000-2aa2278b000 /usr/bin/cat
2aa22f4e000-2aa22f6f000 [heap]
3ff8b000000-3ff8b1db000 libc.so
3ff8b380000-3ff8b3af000 ld.so
3ffdc6da000-3ffdc6fb000 [stack]
and without:
2aa00000000-2aa0000b000 /usr/bin/cat
2aa0000b000-2aa0002c000 [heap]
3fff7c00000-3fff7ddb000 libc.so
3fff7f80000-3fff7faf000 ld.so
3fffffda000-3ffffffb000 [stack]
3ffffffc000-3ffffffe000 [vvar]
3ffffffe000-40000000000 [vdso]
I assume this issue is s390-specific. I will talk to our kernel-guys. I
think the behavior when ld.so is called directly without randomization
should be the same as if activated and the heap should be located
somewhere at 0x2aa00000000
prev parent reply other threads:[~2023-09-21 13:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 15:48 Florian Weimer
2023-09-19 14:32 ` Stefan Liebler
2023-09-19 17:35 ` Florian Weimer
2023-09-20 14:35 ` Stefan Liebler
2023-09-20 15:31 ` Florian Weimer
2023-09-21 13:05 ` Stefan Liebler [this message]
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=8c8dba8c-0e22-cd93-48e8-27482b3bc157@linux.ibm.com \
--to=stli@linux.ibm.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.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).