From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52908 invoked by alias); 17 May 2017 15:48:44 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 46267 invoked by uid 89); 17 May 2017 15:48:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,URIBL_SBL autolearn=no version=3.3.2 spammy=retroactively, D*info, on-hold, hacked X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 May 2017 15:48:27 +0000 Received: by mail-wm0-f41.google.com with SMTP id d127so20962909wmf.0 for ; Wed, 17 May 2017 08:48:26 -0700 (PDT) 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=NRiQKwYlZs7HsTlvhHRHsXv/ZAcBFrCmDNn7n/V+pBU=; b=HPB7g2xQoTtsq6VrVQDbFYQRahLaGfyNa5qPhQDeeZ8Cjv3nnlm7cxZBxw3zMIeSnZ yhkIymzAGwlfv55ta09UUGh+tYkwQB7oVyI9W4PV25p0zobKngcMWyYEK3JpFTl4b/6d M2Iv4xgCM7PqCYZyG4hyf9UuuEVyTVSVBWzEFH+sH/hVc2EhcQJQXJJis4f9pWDQAx+P Qw8T43qzecbqqyAVaYtXhK7DK8kNwbhlZ49RUzZZ27Co22ixzoXxLbTowlMDhU4JTMQ/ bcZNyngF1Nfp6WIMO50nA+nxgKwyCh6KSTmGj0mkkFYh3+7Wj3AUM9I4VaHRuYY4mHlE 9L8Q== X-Gm-Message-State: AODbwcCVZMDDWZtLdNeklpNSoxdnFUbecPjjbyeuTgfoxpJgt2EU0ynk wEKRbRLTjbTxJ1dEFF4= X-Received: by 10.28.47.88 with SMTP id v85mr12579134wmv.110.1495036104971; Wed, 17 May 2017 08:48:24 -0700 (PDT) Received: from localhost (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by smtp.gmail.com with ESMTPSA id w186sm4080075wme.26.2017.05.17.08.48.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 08:48:24 -0700 (PDT) Date: Wed, 17 May 2017 15:48:00 -0000 From: Andrew Burgess To: Petr Ovtchenkov Cc: Nick Clifton , binutils@sourceware.org Subject: Re: [RFC] ld: Add random filling for unspecified section contents Message-ID: <20170517154814.GB2852@embecosm.com> References: <1492209614-13110-1-git-send-email-andrew.burgess@embecosm.com> <20170426092640.GI27726@embecosm.com> <5a0bdc01-02c0-0680-2111-1b1c2bafb520@redhat.com> <20170509163622.GQ16262@embecosm.com> <20170515185815.46a6fd6a@void-ptr.info> <8dba78f6-c0ba-918f-3ae9-94092e787433@redhat.com> <20170516102411.191a1d1a@void-ptr.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170516102411.191a1d1a@void-ptr.info> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00205.txt.bz2 * Petr Ovtchenkov [2017-05-16 10:24:11 +0300]: > Good day, > > On Mon, 15 May 2017 17:43:00 +0100 > Nick Clifton wrote: > > > > > > Do you consider pros/contras for "Add random filling for unspecified section contents", > > > in particular with relation to "Reproducible Builds" issue? > > > > Part of the proposal did include a new linker command line option to set > > the seed for random number generation, so that reproducible, random > > contents would be generated. > > Reproducible pseudo-random filling? Hmm, is any sense in this? I feel compelled to write a small defence of the patch, even though I consider the issue indefinitely on-hold....for now. Obviously in the intended use case reproducibility was not critical, though even that would have been fine (see below), I added that feature specifically so that anyone who was stuck with a script that included random fill could still achieve reproducible builds (though this would loose some of the randomness) without having to change any of the program source (and I include the linker script as source). The primary goal for the patch was to avoid filling between input sections, and after input sections with an obvious pattern (all zero, or some other easy to spot pattern). Actually, if a particular product build always created the same pseudo-random sequence then that would be fine. As Nick pointed out, within the context of an ELF random fill doesn't really offer much, but my interest is more for targets where the section contents are extracted from the ELF and flashed onto embeded devices. Nick also pointed out (and this is what I originally hacked together before I put forward this patch) that we can parse the linker map file and use this to retroactively overwrite the fill with random data afterwards. It's not nice, but it works, at least until I can find a suitable bribe to slip to Nick ;-) Thanks, Andrew