From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93830 invoked by alias); 2 Dec 2019 18:54:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 93774 invoked by uid 89); 2 Dec 2019 18:54:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=UD:ro X-HELO: mail-qk1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T/n1tMOlh0JiP0SroAswYifckpaYhqeKdc3Wj0PCaY0=; b=GFMIbbAkLqpBp5p4855LyAZ8vbhjhyFBEHfT2Ft7yMXCADjYVyM+9DN8hKnIW82q8b f++JwgSOxJC2mlqNdQPngobSVy4FgkA2u8iLyUdBxaCvkLrbQBqWFHSEGwqwzdgQpYV7 ieHyiAyNiXhUhCAOmwkbLxy+ZVpj2XkgszNoT5BXrfsqAcpLAWByyZAKU92zdIl91GOC +DGSofJ+F3lbjiPnkWOd45raoON57Jtib9INLtlsuNH7Fas8kIwybgjgCGaxy1zr1smf XRkMNjTNKTnxSpEO61Pcp6lhfutSWUJjLgI4aqEqBxvUu+MEqp0qd6PZOYn9sQIiO6Xx oxbw== Return-Path: To: Florian Weimer Cc: libc-alpha@sourceware.org References: <20191129210327.26434-1-adhemerval.zanella@linaro.org> <20191129210327.26434-5-adhemerval.zanella@linaro.org> <874kykfjyy.fsf@mid.deneb.enyo.de> <104ece90-2d18-d655-dafd-1084e32a9c4f@linaro.org> <87h82iy48o.fsf@mid.deneb.enyo.de> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: [PATCH 5/7] elf: Enable relro for static build Message-ID: <8dc5bbdc-f0fa-03ad-1289-2b1b55f035c1@linaro.org> Date: Mon, 02 Dec 2019 18:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87h82iy48o.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-12/txt/msg00060.txt.bz2 On 02/12/2019 15:25, Florian Weimer wrote: > * Adhemerval Zanella: > >>> Somewhat bizarrely, full RELRO for statically linked binaries >>> requires linking with -z now. > >> My understanding it is arch-specific and also depends on how >> bintuils was build. For instance, with my system ld (GNU ld (GNU >> Binutils for Ubuntu) 2.30) seemed to be built with >> DEFAULT_LD_Z_RELRO (set by --enable-relro) which sets relro by >> default. With this binutils I could only disable relro by explicit >> add norelro, the -z {lazy,now} did not change the GNU_RELRO header >> creation. > > Whether -z relro gives you full RELRO depends somewhat on the > architecture and what relocations can be eliminated from the static > link. Objects built with -fPIC tend to leave relocations behind, > though, and to protect them, you need -z now. > I was investigating in fact if binutils is requiring the -z now to actually enable full RELRO, but it seems that there is no option to actually set 'full RELRO' besides the combination of -z now and -z relro. And I think it is worth to check for static PIE as well. At least for partial relro, .data.rel.ro seems to protect the required data. About testing, I am not sure what kind of coverage we are aiming here. My initial approach would to check if a write on a variable set to .data.rel.so does trigger a SEGSEGV signal and check with some different combinations (-z now, -z lazy, static, dynamic, pie, nopie). Do you have something more elaborated in mind?