Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1350597ybv; Thu, 6 Feb 2020 02:33:20 -0800 (PST) X-Google-Smtp-Source: APXvYqxI46ndW64rmSC3FW47wq6E0IGH60PqhaXmRnHpEi7AcOZywgs4BDuxNpWXU7KvLkOFo0JX X-Received: by 2002:aca:5746:: with SMTP id l67mr6486158oib.60.1580985200529; Thu, 06 Feb 2020 02:33:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580985200; cv=none; d=google.com; s=arc-20160816; b=MTlG0jY59UKGYjn5toX7iBJ/QBlzs1wOiSLshGXjLj4HBnKx1o89YISPYiprOxk+i9 WhQ8NlspQUqBDt16Yx2mORc1iad4vIGi4u+Z+TDERLqPQwg25QweAth/rg55XjxuUpSG rLH1Lh1YLBrFyK3ciViQyyHQwAuaH/I5uiAK6R3udZdwWO7D6rF6SNK0Rys1e26Mbrsj dOirJkRgeGywkXo45+1NeeIOo8QIfK4X0wMAIw1jOfnCleAIFzPzvuodBnJO0j2hBPVl 0NE/NN8Ltqr88L18+LvD038+e+sGXdrJn/gmuDMZjLtgfz5XQODQwphlCO3qR1mABZpV R8xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=doRr41+uHYQPX4/to1I/1srPnHzm/CaLlIXj8w9Vubs=; b=kle3F7HElj9MghYPierGrafAf78I4l4d8O7U5t35lnzWPInMe9WuMGfPV/vjqdjZRv CXy27xD2N8O0yNaqzTvhuNcjwn1Fa4DSawz8WsoDKfdrJgJPlAqE3ulwlFCdvdAJpW3R VMWMEn5iwuQKnX8B52cy22b/X+yr+LJD4TDE6Hd2PrqvhLjbpScUwgak+PDkV7jQMNm/ C2Ts2xNzJfm/Qo/7alH8zI0PvXUVgLLHZ3hhZQskS/hv2rXAxGz36XwOR0GHlaokyDrk ac4CCxi4vMVoqg71UPKgDYBKB+R8r7hfliCVP9rnaVLAH9g4tSgB8RXfNgfCCBio4Tj8 WP7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=O9XIG10R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y20si1707459otq.190.2020.02.06.02.33.07; Thu, 06 Feb 2020 02:33:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=O9XIG10R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728483AbgBFKbM (ORCPT + 99 others); Thu, 6 Feb 2020 05:31:12 -0500 Received: from merlin.infradead.org ([205.233.59.134]:36168 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728261AbgBFKbM (ORCPT ); Thu, 6 Feb 2020 05:31:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=doRr41+uHYQPX4/to1I/1srPnHzm/CaLlIXj8w9Vubs=; b=O9XIG10RJTp9t1KXQg2NFLAhGf +gipjAzct3zUGo4Hyf9EXunyT5NgIUBfSiRIcZJt8HPofZwC8xQet/QxB0qiVlRipsJYmF1Nvm96k cQZQmF1xIcEPKZcvzf3CkUzkhwNWRV1SpwSsdISIhizHw7pz61xKYs7HxGgghNYyVtkQlt3f+9JHG Fb4dZblXX3+XwHvlmeJoP0sm0Wl0Plbx9z2G5OZtxM9AMBT1WU/sZkZRALvH9fpuNj8TrigZBSNH9 Z+M8+QiUbaQzhsyC0BtstPUOnyUpGp7GvoV7zWtNYZ4i11n9mcGWZHr300AVj0uwgpw+hRo2dvhJx FJXyLhTw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1izeR0-0007UO-4E; Thu, 06 Feb 2020 10:30:58 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 15F553007F2; Thu, 6 Feb 2020 11:29:09 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 6F9132B789F42; Thu, 6 Feb 2020 11:30:55 +0100 (CET) Date: Thu, 6 Feb 2020 11:30:55 +0100 From: Peter Zijlstra To: Kristen Carlson Accardi Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, arjan@linux.intel.com, keescook@chromium.org, rick.p.edgecombe@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [RFC PATCH 05/11] x86: Makefile: Add build and config option for CONFIG_FG_KASLR Message-ID: <20200206103055.GV14879@hirez.programming.kicks-ass.net> References: <20200205223950.1212394-1-kristen@linux.intel.com> <20200205223950.1212394-6-kristen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200205223950.1212394-6-kristen@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 05, 2020 at 02:39:44PM -0800, Kristen Carlson Accardi wrote: > Allow user to select CONFIG_FG_KASLR if dependencies are met. Change > the make file to build with -ffunction-sections if CONFIG_FG_KASLR > > Signed-off-by: Kristen Carlson Accardi > --- > Makefile | 4 ++++ > arch/x86/Kconfig | 13 +++++++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/Makefile b/Makefile > index c50ef91f6136..41438a921666 100644 > --- a/Makefile > +++ b/Makefile > @@ -846,6 +846,10 @@ ifdef CONFIG_LIVEPATCH > KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone) > endif > > +ifdef CONFIG_FG_KASLR > +KBUILD_CFLAGS += -ffunction-sections > +endif The GCC manual has: -ffunction-sections -fdata-sections Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section’s name in the output file. Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format have linkers with such optimizations. On AIX, the linker rearranges sections (CSECTs) based on the call graph. The performance impact varies. Together with a linker garbage collection (linker --gc-sections option) these options may lead to smaller statically-linked executables (after stripping). On ELF/DWARF systems these options do not degenerate the quality of the debug information. There could be issues with other object files/debug info formats. Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. These options affect code generation. They prevent optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown until link time. An example of such an optimization is relaxing calls to short call instructions. In particular: "They prevent optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown until link time." I suppose in practise this only means tail-calls are affected and will no longer use JMP.d8. Or are more things affected? (Also, should not the next patch come before this one?)