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,HTML_MESSAGE,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 0234e365 for ; Fri, 31 Jan 2020 19:11:46 +0000 (UTC) Received: (qmail 13336 invoked by uid 550); 31 Jan 2020 19:11:45 -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 13318 invoked from network); 31 Jan 2020 19:11:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jYkBuprDudDH+hJ9lZPWHj/c7XZhbhtIQsMAcISD5vw=; b=n0XtXA98ZkGiQjvU8RqKbAiT7DrUJxI5b/Yce5JtZnKXhVDopEeo9z/DS0Gskdfr8e yKI83SqxoeYtOXsHMxYp9pvoJ1n8jP5UATeohya9MY3wfSyRCk6UWLaW/zYsjjcY9Bi0 UHPASjc5enlAmHKyWIUIeYPhTkbi5qg/ktwZ/utbbBJRIsJ1tktQuWDRiKaWdxBgMYLO SFqwpNGVHlir7PxxbNXtf7JofwT4ye5ik4QFyPThOcuwXhLJecj2aRNwRZYR5V7QLiX3 FHaIzF8+hH41arRXi7loqXde+0lX6UsfUwCQo83OBIoBX/5eejRJA2qmfklu3DlzAhuo XgUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jYkBuprDudDH+hJ9lZPWHj/c7XZhbhtIQsMAcISD5vw=; b=s0wkyslhNcK0JSw/ZT18hhVhu+hwIo5/m51vc1tIZY7KAxebo8TaAuZcODtRKD+v3n gvyvKZ8aoXlsW7lao1Qp1mHYOOQCtreSFnl5mB078hT2fbsUKbFW6Vfs2DDApVl6c7vq uPNJEOMPps/DkDXPnIhsHFVrLOXuqprhFnHonm6IeXV0Lfh3YjF/MlXWJBk4ravZYU6c LlI1Y4RHbsTtxLHBqn796X1GBaKkJkR+1w/jMWnW/V9F6Y1P/MU46f1+O2isrbbNMGoY 0S42XZ3XxpIeFodcTxJZA4oVvTnKwCQFAwAZx3m6pXs2G/JnVJ+JGWdf1/mpyRmVfDWr G/fw== X-Gm-Message-State: APjAAAWLboezrsyE+ewQh5KLsZcN2fMnPHU4z3uS3wpQgH2P9nejJwvR MSC7miO0IhKiltsN7cMzMRSUBdH8JOH+9s+ukXMABU98gL4= X-Google-Smtp-Source: APXvYqz+635gHRPqHbPf0LdEGI9XvDOlAnu3X1iyTVZGPfIFTUhV3Bo0ei9tPJzb15DAFsUpx4oOX97JV61ZS+E8FVA= X-Received: by 2002:a2e:9ad0:: with SMTP id p16mr7109442ljj.111.1580497893047; Fri, 31 Jan 2020 11:11:33 -0800 (PST) MIME-Version: 1.0 References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> <20200131164009.GI1663@brightrain.aerifal.cx> <20200131180109.GJ1663@brightrain.aerifal.cx> In-Reply-To: <20200131180109.GJ1663@brightrain.aerifal.cx> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCQ0LvQsNC00YzQtdCy?= Date: Fri, 31 Jan 2020 22:11:21 +0300 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000007bc3c7059d745701" Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment --0000000000007bc3c7059d745701 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Now everything is clear, thank you. Have a good weekend =3D) =D0=BF=D1=82, 31 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 21:01, Rich Felker= : > On Fri, Jan 31, 2020 at 08:51:05PM +0300, =D0=90=D0=BD=D0=B4=D1=80=D0=B5= =D0=B9 =D0=90=D0=BB=D0=B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote: > > > Moreover, adding such a thing is not desirable because it adds a > > linear-search of an array of load segments to each relocation > > > > I think it is possible to make this search O(log n). > > This would help if n were large, but in practice it's very small (2-3 > or maybe 4) and the cost is just the code path overhead, which gets > worse if you do that, not the largeness of n. > > > for (j=3D0; v-p->loadmap->segs[j].p_vaddr >=3D p->loadmap->segs[j].p_me= msz; > > j++); > > > > This code takes first segment that can handle address. It looks possibl= e > to > > create modified list of virtual segments, that won't overlap and make a > > binary search. > > They're non-overlapping anyway but not necessarily sorted, and can't > be simultaneously sorted by addr and p_vaddr since the orders will > differ. > > > > This is not a reasonable tradeoff and it's why I proposed the "hull" > > approach > > > > It may not be safe from maintainability perspective. Library will be > > changed, everybody will forget what part of code was protected by > external > > validation and it will provide unexpected behaviour. Please consider > double > > validation approach: > > You're really not making sense here. What does "protected by external > validation" mean? There is presently nothing being "protected" here; > the discussion is just about more informative errors. If this is used > as a boundary for some sort of safety at some point in the future (as > mentioned before, the benefit of this is probably limited to ldd and > thus not very useful) then it will be done according to constraints > needed to achieve that. > > > external validation in production and debug only mode > > with loadmap like validation. > > We do not have separate "production" and "debug" modes. This kind of > thing (combinatoric build-time options) is what lacks maintainability. > > Rich > --0000000000007bc3c7059d745701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now everything is clear, thank you.=C2=A0Have a good weeke= nd =3D)

=D0=BF=D1=82, 31 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 21:01, Rich= Felker <dalias@libc.org>:
=
On Fri, Jan 31, 202= 0 at 08:51:05PM +0300, =D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9 =D0=90=D0=BB=D0= =B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote:
> > Moreover, adding such a thing is not desirable because it adds a<= br> > linear-search of an array of load segments to each relocation
>
> I think it is possible to make this search O(log n).

This would help if n were large, but in practice it's very small (2-3 or maybe 4) and the cost is just the code path overhead, which gets
worse if you do that, not the largeness of n.

> for (j=3D0; v-p->loadmap->segs[j].p_vaddr >=3D p->loadmap-= >segs[j].p_memsz;
> j++);
>
> This code takes first segment that can handle address. It looks possib= le to
> create modified list of virtual segments, that won't overlap and m= ake a
> binary search.

They're non-overlapping anyway but not necessarily sorted, and can'= t
be simultaneously sorted by addr and p_vaddr since the orders will
differ.

> > This is not a reasonable tradeoff and it's why I proposed the= "hull"
> approach
>
> It may not be safe from maintainability perspective. Library will be > changed, everybody will forget what part of code was protected by exte= rnal
> validation and it will provide unexpected behaviour. Please consider d= ouble
> validation approach:

You're really not making sense here. What does "protected by exter= nal
validation" mean? There is presently nothing being "protected&quo= t; here;
the discussion is just about more informative errors. If this is used
as a boundary for some sort of safety at some point in the future (as
mentioned before, the benefit of this is probably limited to ldd and
thus not very useful) then it will be done according to constraints
needed to achieve that.

> external validation in production and debug only mode
> with loadmap like validation.

We do not have separate "production" and "debug" modes.= This kind of
thing (combinatoric build-time options) is what lacks maintainability.

Rich
--0000000000007bc3c7059d745701--