From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14568 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Fangrui Song Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: size of executable Date: Tue, 13 Aug 2019 11:45:43 +0000 Message-ID: <20190813114251.jidhp3vgsvyidhnt@gmail.com> References: <20190812171851.GS9017@brightrain.aerifal.cx> <20190812182302.GW9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="182177"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180223-112-0c5bf3 Cc: musl@lists.openwall.com To: Micha Nelissen Original-X-From: musl-return-14584-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 13 13:46:01 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hxVFZ-000lDr-JI for gllmg-musl@m.gmane.org; Tue, 13 Aug 2019 13:46:01 +0200 Original-Received: (qmail 23601 invoked by uid 550); 13 Aug 2019 11:45:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23583 invoked from network); 13 Aug 2019 11:45:58 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BOv208KPCLKqEnYQbAAFxg2hbQ+zUVkExb+okf6uy2w=; b=YS+JS4OGmwa0wkFnc+omOnoMZ1SajgoAWbZYM5gofzpys6Gt6ZTstODf2bKGBQaBE2 IZGYNZBcieknMFwIaF3pZ2jr68TJ0MFNsiJIOHJ3hozUbpbx/ikx8OUxpOn1DWAv/4Yr UXRu4049IuEB8C3YmTCOgX1S+aQM1RxK5/1qiiSs4Sy/HeZTCEa0+sQaPh+TeJG/+UkZ 8KHjykE1UOgTjvPVgdbI7y8KGjx8ftdC/8KKiUEkbxSI+yBMlNkgv5Jrm9R7MTwzJZ0A o5ZDBmlYhIM/I1cR2TYc2AYcSCXhTSDLP3Jyqi+f9Ji+5CrmURs3pEz2vhTj+gOxX1z7 VMPQ== X-Gm-Message-State: APjAAAWFczyX2dBxNpv3WvqzRoh66wthTUpOrMlKih+2xv/jvfXJxLxA o7aIX79zKicB2w6aSGphWts= X-Google-Smtp-Source: APXvYqxu3HhhXnYEzWgt5YCMIhUIqZrURIm54ImQw70BZpZcyH5/HlXOSAPOX5kUVaZSywD/9leMUw== X-Received: by 2002:a17:902:244:: with SMTP id 62mr36981320plc.243.1565696746044; Tue, 13 Aug 2019 04:45:46 -0700 (PDT) Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14568 Archived-At: On 2019-08-13, Micha Nelissen wrote: >On 12-08-2019 20:23, Rich Felker wrote: >>On Mon, Aug 12, 2019 at 11:16:39AM -0700, Khem Raj wrote: >>>On Mon, Aug 12, 2019 at 10:19 AM Rich Felker wrote: >>>>On Mon, Aug 12, 2019 at 05:55:28PM +0100, Jorge Almeida wrote: >>>>>On Mon, Aug 12, 2019 at 5:48 PM Jorge Almeida wrote: >>>>>>I get 16768 bytes (not stripped) and 12324 (stripped). >>>> >>>>This is a binutils regression from a dubious anti-ROP feature, -z >>>>separate-code. Add -Wl,-z,noseparate-code and it will go away. >>> >>>is this still so with latest release as well. >> >>The breakage that caused separate-code to crash at runtime was fixed >>between 2.31 and 2.32, but the size and performance regression >>remains. With separate-code, a couple extra pages of memory and disk >>are needed, with corresponding runtime cost to mmap them properly. >> >>All to avoid ROP gadgets, when every single dynamic-linked program has >>a nice ROP gadget named "system" (among many others) in it... > >I'm curious. Jorge reports that the executable goes from 12k to 4k. >That suggests two pages saved? But if I look at documentation for this >separate-code option, then it says to allocate a separate code PT_LOAD >segment. (PT_LOAD just means loadable?) That would suggest up to 4k >more usage, not 8k right? One extra page necessary. Are by default >rodata and code combined but with separate-code those are separated? >Or something more happening? binutils 2.31 includes a change "ld: Add --enable-separate-code". This is enabled by default for Linux x86. You can compile a trivial program with -z separate-code and -z noseparate-code, run readelf -l and compare the results. -z noseparate-code LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0007d8 0x0007d8 R E 0x1000 LOAD 0x000e18 0x0000000000001e18 0x0000000000001e18 0x000210 0x000218 RW 0x1000 -z separate-code LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x000530 0x000530 R 0x1000 LOAD 0x001000 0x0000000000001000 0x0000000000001000 0x0001cd 0x0001cd R E 0x1000 LOAD 0x002000 0x0000000000002000 0x0000000000002000 0x000148 0x000148 R 0x1000 LOAD 0x002e18 0x0000000000003e18 0x0000000000003e18 0x000210 0x000218 RW 0x1000 -z separate-code has two more PT_LOAD segments. What is bad is that the two PT_LOAD segments have aligned p_offset: diff -u =(ld.bfd --verbose -z noseparate-code) =(ld.bfd --verbose -z separate-code) + . = ALIGN(CONSTANT (MAXPAGESIZE)); + . = ALIGN(CONSTANT (MAXPAGESIZE)); + /* Adjust the address for the rodata segment. We want to adjust up to + the same address within the page on the next page up. */ + . = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1))); This disables an important size optimization (I have some description in https://reviews.llvm.org/D64906)