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=-3.0 required=5.0 tests=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 b0b67633 for ; Wed, 26 Feb 2020 18:40:18 +0000 (UTC) Received: (qmail 30684 invoked by uid 550); 26 Feb 2020 18:40:17 -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 30663 invoked from network); 26 Feb 2020 18:40:16 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20200226052448.GA2769@voyager> <20200226173621.GA11469@brightrain.aerifal.cx> Date: Wed, 26 Feb 2020 19:38:31 +0100 In-Reply-To: <20200226173621.GA11469@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 26 Feb 2020 12:36:21 -0500") Message-ID: <87a7556vo8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] [PATCH] Add REL_COPY size change detection * Rich Felker: > 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. Unfortunately the Mozilla NSS people disagree that size mismatches for global symbols are an ABI break. I don't know if this is relevant in the musl context, but it means that for glibc, we probably can't make it a hard error. I want to have better diagnostics for this in glibc, but the current warning (which is poorly worded at that) is in the architecture-specific code, and I got side-tracked when I tried to clean this up the last time.