From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 1b6178e3 for ; Wed, 26 Feb 2020 20:12:16 +0000 (UTC) Received: (qmail 1524 invoked by uid 550); 26 Feb 2020 20:12:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1506 invoked from network); 26 Feb 2020 20:12:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582747922; bh=hXWl8/l6bSkrID2nKMVeCw2jgrVLFltpVgtAA5HVTjI=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=djvVPcjL1EaKp8oK3JkKBv/mXyAetmajM6PGBpkOzj/5ffJGHUsU/PQb+XGzywsMy xCTIFH3m9XoGUty/vFthERZ+4PRG289wsJWIi6HPyfNNJ2Dna4V4qYU43R10Vpr0JW J0r4EFN7VEeR1VF+5/i8eGr4H038dygdpc6BsWlk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 26 Feb 2020 21:12:02 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200226201202.GB2769@voyager> References: <20200226052448.GA2769@voyager> <20200226173621.GA11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200226173621.GA11469@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:/Y+oWb8EAG+IpeShsdVOM2a/zanNFoXM8rGuQhcEienx4z919fj Vi1ToHuxuK3IHVdNxccBrT96jfeh7hzSTQL9PIr1g+wc2xngVwFk9gvWBIWP+73FKit8TMX /oKm372Jh2B8DpmjwOV1lfdZ0+ZgX020ztnI3Wv6Vo4bzpszsyjtX1G7ba1XLRQJsQRYQI/ 05/UiIqxBKxe1RSb/ErZg== X-UI-Out-Filterresults: notjunk:1;V03:K0:PA9oOx4S4g8=:l8XAra7TlEb76n3H9NbGgB q4EKJWsTtJucMYIYY17oUfTs99s9EfDvIJY89ameNkNt2Wmv1o7Sbxg3EgM41Ub+kDz8kubHu MvzqZ+rQ8Y5zcoHwHSu6P8zNtLgVq5rMTbYMKM+DMJHXt4Gc+x8fo9w4HaJEW8dOhU/Kc9nCG AL/rwAXKQ1LxNsOqmR6U6MR0ybBgwqlABTrJrZhcyi3ArFtMfn4sChRlP0zcRvzbpNK5jNs7R XXepUPgNHchCZW2F96UPl0gadsr74xRnhZfOc/NH1mE62PDoV8Nlm4ieUq3+2IupUVIa0Rw3g ySPtiIV3kVPMl7PYISn7gEllYXpsiWBhV1+TQr07Hne5fwK7YQ2Lt59ix+B9goHnzClNtzs5W OT0HM/ukG2qn9FSByYXCsquHt4zE8JKP05vKbKYqVgz21oN9NTegVxms3uKpe42gp2mHjg1o9 PnUxhTQqiG11VTtNgeBuF1ebTPxQRr1tpigB1iNa7r++QofF57fHntLtvfjBi5S7tFMzf5XMa E1Mr6Zd5rTbFP1pCAKZH+XoZsbqtb66MMjR65zmqSXjzIavkFNoyWjNctb1BYIAYK1N8KIHJb RGu/dfWTzJbs+4U0flReQzBHl0QoJzc9K1oBEnJOd0ULM1QNqnc+7MBFRK6fq7lrUXxQkZtlu IEuslX7R9AWIPr+//VQlGFA/FQpup4eCZ6oEIWw4prz7QJ9y504jIuaOGdlwzgtzToDLhAx4m i6sbfVdRiaxk5rA0movkFY4Th74pSYojKdyJ46Bhgzg+XQEohrc1JpJy2cSatjf8NFBdD9URT oWLxJC8kVdlij1vFHFN4uKr+kUNscjzRYOoC+GyoosbNfbliB4S5sWGfBKr9S7OX//XiRVUsp hoUiyGXpKKngi5dJydt7EhToRP1KOTAOunz6QDsvaWoC73ppyDaDOKih2nccXtPmAYKm0qhM8 iAT/Hq7cfIB6kZdMiXO+tuxXIIzBh5UfgC2ItkWy8aqSX/ZSeIrAhHra83WVx8wLh/xWwZnbl nc1P407ZerrSBPYpN5xQuwDAyX0G+eqV+1ccFubyCMQ+wODcJ1VLMZbsRg9JGtxEgaHtqTxZl HLGP8G1Gwp0U3cK3ycIuNb1rXYuiQco8b++8up37EAAIYEPtVz/4U6xOL+FMUta16dOqoroIC B4gQLDZlyXPkM8mdCcehJfB/oiiN/ax1OYG85avDif3XABqcKSYSsmwovjApks/1a0MoyTRcd 4MnTjmKv4elvNriPW Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] Add REL_COPY size change detection On Wed, Feb 26, 2020 at 12:36:21PM -0500, Rich Felker wrote: > In theory copy relocations should have been gone for everyone who > switched to PIE, but then the gcc/binutils folks brought them back as > an "optimization" (allowing pc-rel access to external symbols). :-( > Several quotes about optimization come to mind. Especially ones with the word "premature" in them. I just checked and I saw that there are no copy relocs in my libraries, but my binaries are indeed PIEs. Therefore I have to conclude that gcc compiles PIE and PIC differently. Weren't they meant to be the same, except maybe for the selection of object files during the linker phase? > At the very least I think we ought to catch and error on the case > where def.sym->st_size>sym->st_size, since we can't honor it and > failure to honor it can produce silent memory corruption. I'm less > sure about what to do if def.sym->st_sizest-size; this case > seems safe and might be desirable not to break (I vaguely recall an > intent that it be ok), but if you think there are reasons it's > dangerous I'm ok with disallowing it too. I'm having a hard time now > thinking of a reason it would really help to support that, anyway. > If the application did import sym->st_size bytes, it probably wanted to do something with them. Finding less than that at the symbol and garbage afterwards (and, from the point of view of the dynlinker, you have no way of knowing what counts as garbage and what doesn't) might break the program. Sometimes. That is exactly the kind of rare subtle breakage I added the error for. > Missing , after name, and the indent is weird (2 extra levels). I'd > either align (spaces) with the opening paren or use just one indent > level, and fewer lines. > The missing comma is weird. Must have gone missing as I was cutting that line down to size (originally, I had this as one line, but then it was around 200 columns long, and I thought that was a bit excessive). So then I tried to stay below 80 and you see the result before you. The indent was just vim's default setting. Usually this suits me, but usually I have shiftwidth=3D4 and expandtab. For musl, it's sw=3D8 and noe= t. > Semantically, st_size is size_t not ulong, so I'd probably lean > towards a cast to (size_t) here with %zu. > Isn't on Linux size_t always a ulong? I will admit I only went for ulong because it's easier to write the cast. Ciao, Markus