From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:12:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D6CB1B0; Fri, 17 Oct 2014 13:12:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2017F690; Fri, 17 Oct 2014 13:12:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9HDC0jw003249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 16:12:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9HDC0jw003249 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9HDC02G003248; Fri, 17 Oct 2014 16:12:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Oct 2014 16:12:00 +0300 From: Konstantin Belousov To: Shawn Webb Subject: Re: PIE/PIC support on base Message-ID: <20141017131159.GD2153@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , PaX Team , Sean Bruno , freebsd-arch@freebsd.org, Jeremie Le Hen , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:12:08 -0000 On Thu, Oct 16, 2014 at 06:15:38PM -0400, Shawn Webb wrote: > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: > > > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > wrote: > > > > > > I chose the "atomic" approach, at the moment very few binaries are > > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed > > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if > > you > > > include (which include ...) otherwise > > other > > > binaries include as usual hence does not apply. Look > > > reasonable approach ? > > > > I think I understand what you mean. But I think PIE is commonplace > > nowadays and I don't understand what you win by not enabling it for > > the whole system. Is it a performance concern? Is it to preserve > > conservative minds from to much change? :) > > > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. > > On i386, there is a performance cost due to not having an extra register > available for the relocation work that has to happen. PIE doesn't carry > much of a performance penalty on amd64, though it still does carry some on > first resolution of functions (due to the extra relocation step the RTLD > has to worry about). On amd64, after symbol resolution has taken place, > there is no further performance penalty due to amd64 having an extra > register to use for PIE/PIC. I'm unsure what, if any, performance penalty > PIE carries on ARM, AArch64, and sparc64. -fPIE generates PIC code, in particular, the main binary symbols are resolved through GOT (and functions are called through PLT). This is additional level of indirection, which causes additional memory access outside of the instruction stream reads. Also, for the same reason, PIE changes ELF rules for the symbol resolution. In particular, symbols from the main binary appear in the dynamic symbol table, and are the subject of interposing. > > Certain folk would prefer to see PIE enabled only in certain applications. > /bin/ls can't really make much use of PIE. But sshd can. I personally would > like to see all of base's applications compiled as PIEs, but that's a long > ways off. It took OpenBSD several years to accomplish that. Having certain > high-visibility applications (like sshd, inetd, etc) is a great start. > Providing a framework for application developers to opt their application > into PIE is another great start. Exercise for certain folks: how does dynamic loading of the PAM modules interacts with PIE ? Hint: see above about dynamic symbols and interposing. > > Those are my two cents. > > Thanks, > > Shawn