From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5A6A0385AE43; Thu, 7 Dec 2023 09:30:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A6A0385AE43 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701941405; bh=Bv7gTfmiwSVuqRVAhaqjrghXJYxkUMzPKaM0v9iGOCw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TyWNyLGo9vWkZK8e3BZjtsMK6rX3xTLq1i6F4Rulm3i3Zz4d7RVP8KQK7swD9qBIH Id//EeKFrsXfipyOUmP4SgE5xrCA+X/TC+JtvBfGaogvTeRklpm9w+sPTAjBn1lCYV ypY19T49hwBVlEJ8PBPwEisTX57ZlMRXbRFCuDog= From: "fweimer at redhat dot com" 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: Thu, 07 Dec 2023 09:30:01 +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: fweimer at redhat dot com 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: security- 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 #20 from Florian Weimer --- (In reply to Fangrui Song from comment #19) > (In reply to Florian Weimer from comment #18) > > (In reply to Kalesh Singh from comment #15) > > > AIUI if the runtime-page-size equals the max-page-size, the holes are= also > > > mapped in as part of the segment mapping and share the same permissio= ns. > > > Does this mean that on such systems, any protection it offers becomes= void? > >=20 > > That's my understanding. The current behavior gives programmers the *op= tion* > > to avoid mapping extra code on small-page systems, while maintaining > > compatibility with large-page systems. The proposed change to over-map = to > > the next load-segment, to fill the gap, would take away that option. >=20 > Can you elaborate what the option (and "functionality" below) is? Since > 22930c9bf21ea15d0da1477a379029e2de259b69 (1996) rtld just calls `mprotect` > (one > extra `struct vm_area_struct` instance, see `sudo grep vm_area_struct > /proc/slabinfo`), and the user has no option to control this behavior. The developer can produce a binary with a LOAD segment that does not need t= hat mprotect call. > > Unmapping (to create a gap) has compatibility implications. >=20 > I wonder the implications are. If they are related to l_contiguous not > accounted for correctly, the user needs to be fixed. We do not set l_contiguous for the dynamic loader, and it's an internal variable. The bug we have is that we assume (without checking) the the load= er is mapped contiguously although the kernel does not do that. We have feedback from downstream that some tools break if the gaps are so l= arge that objects are mapped in the gaps of other objects. This is particularly visible on x86-64 when objects linked with different binutils versions/flags are loaded because the gaps can be quite large due to 2 MiB load segment alignment in some builds. Other objects do not do that alignment and are mu= ch smaller than 2 MiB, and so can fit comfortably into the gaps. I'm worried t= hat if we change loader behavior to munmap instead of mprotect, that we'll retroactively expose these bugs more widely. We obviously need to fix the l_contiguous assumption for ld.so in glibc, ei= ther by making sure that ld.so has contiguous load segments, or assuming in the = code that it does not. --=20 You are receiving this mail because: You are on the CC list for the bug.=