From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 884CA3858C2D; Mon, 27 Nov 2023 17:58:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 884CA3858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701107939; bh=IlGBd8pjUR8zRjwt/eMENj/0clLnpuAwB6qQYIs2X6I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gi1kJgZIqaqs9f9Skbb21FSF5ibkGidtN1hI4+836qPSfTNHueXsyYGz1fduntT94 53CzZXBN5pQC4Beu/f82BLEa6dTqjD7ks+eXP/Ih8inENtX6FO0eOBG6NqpBbpXXgv OAAYXAlXU3Q6av6qZXgyWLSDqfqzTex7rTIFHVzc= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/31076] Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size Date: Mon, 27 Nov 2023 17:58:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31076 --- Comment #11 from Adhemerval Zanella --- (In reply to Florian Weimer from comment #10) > (In reply to Adhemerval Zanella from comment #9) > > (In reply to Florian Weimer from comment #8) > > > (In reply to Adhemerval Zanella from comment #7) > > > > So the mprotect is essentially a hardening feature, assuming that t= he > > > > dynamic object padding/holes might contain gadgets. It still does = not > > > > happen for loader and main program itself, since normally they woul= d be > > > > mapped by the kernel and its does do anything with holes, > > >=20 > > > There's no expectation that these are contiguous in memory, yes. Such= an > > > expectation exists for shared objects loaded by glibc. > >=20 > > Right, but my point is if this is a hardening feature that glibc aims to > > provide it does not help if the kernel still does not provide it for the > > loader (if this is built with a different page size) and the main progr= am > > itself. Should we push for kernel to implement a similar handling? >=20 > The kernel effectively implements the munmap behavior, I think. It creates > unmapped holes, not PROT_MEM reserved holes. It does indeed, which makes me realize that _dl_find_object does not work correctly if the loader is built with -Wl,-z,max-page-size=3D different tha= n the system one. The resulting address of the tst-dl_find_object will be: 0x555555554000 0x555555556000 0x2000 0x0 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-dl_find_object 0x555555556000 0x55555555a000 0x4000 0x2000 r-xp=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-dl_find_object 0x55555555a000 0x55555555c000 0x2000 0x6000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-dl_find_object 0x55555555c000 0x55555555d000 0x1000 0x7000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-dl_find_object 0x55555555d000 0x55555555e000 0x1000 0x8000 rw-p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/tst-dl_find_object 0x7ffff7c00000 0x7ffff7c26000 0x26000 0x0 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so 0x7ffff7c26000 0x7ffff7d9a000 0x174000 0x26000 r-xp=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so 0x7ffff7d9a000 0x7ffff7df1000 0x57000 0x19a000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so 0x7ffff7df1000 0x7ffff7df5000 0x4000 0x1f0000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so 0x7ffff7df5000 0x7ffff7df7000 0x2000 0x1f4000 rw-p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so 0x7ffff7df7000 0x7ffff7e04000 0xd000 0x0 rw-p 0x7ffff7f9d000 0x7ffff7f9e000 0x1000 0x0 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/ld.so 0x7ffff7fad000 0x7ffff7fd3000 0x26000 0x10000 r-xp=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/ld.so 0x7ffff7fdd000 0x7ffff7fe7000 0xa000 0x40000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/ld.so 0x7ffff7fef000 0x7ffff7ff0000 0x1000 0x0 rw-s /dev/= zero (deleted) 0x7ffff7ff0000 0x7ffff7ff5000 0x5000 0x0 rw-p 0x7ffff7ff5000 0x7ffff7ff9000 0x4000 0x0 r--p [vvar] 0x7ffff7ff9000 0x7ffff7ffb000 0x2000 0x0 r-xp [vdso] 0x7ffff7ffb000 0x7ffff7ffd000 0x2000 0x4e000 r--p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/ld.so 0x7ffff7ffd000 0x7ffff7fff000 0x2000 0x50000 rw-p=20=20 /home/azanella/Projects/glibc/build/x86_64-linux-gnu/elf/ld.so 0x7ffffffdd000 0x7ffffffff000 0x22000 0x0 rw-p [stac= k] 0xffffffffff600000 0xffffffffff601000 0x1000 0x0 --xp=20=20 [vsyscall] --=20 You are receiving this mail because: You are on the CC list for the bug.=