From patchwork Fri Feb 5 17:46:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 61338 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp106356lbl; Fri, 5 Feb 2016 09:48:24 -0800 (PST) X-Received: by 10.66.232.202 with SMTP id tq10mr21764066pac.14.1454694504218; Fri, 05 Feb 2016 09:48:24 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id m23si25123518pfi.250.2016.02.05.09.48.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2016 09:48:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aRkTV-0005Ld-Ts; Fri, 05 Feb 2016 17:47:17 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aRkTT-0005IG-0W for linux-arm-kernel@lists.infradead.org; Fri, 05 Feb 2016 17:47:15 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D58123A8; Fri, 5 Feb 2016 09:46:07 -0800 (PST) Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 203583F25F; Fri, 5 Feb 2016 09:46:51 -0800 (PST) Date: Fri, 5 Feb 2016 17:46:49 +0000 From: Catalin Marinas To: Ard Biesheuvel Subject: Re: [PATCH v5sub2 0/8] arm64: implement virtual KASLR Message-ID: <20160205174649.GK6076@e104818-lin.cambridge.arm.com> References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org> <20160205173248.GJ6076@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160205_094715_084566_40F6A0C9 X-CRM114-Status: GOOD ( 25.76 ) X-Spam-Score: -7.2 (-------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-7.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Will Deacon , Kees Cook , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Fri, Feb 05, 2016 at 06:38:33PM +0100, Ard Biesheuvel wrote: > On 5 February 2016 at 18:32, Catalin Marinas wrote: > > On Mon, Feb 01, 2016 at 02:35:03PM +0100, Ard Biesheuvel wrote: > >> On 1 February 2016 at 14:09, Ard Biesheuvel wrote: > >> > At the request of Catalin, this series has been split off from my series > >> > 'arm64: implement support for KASLR v4' [1]. This sub-series deals with > >> > creating a relocatable binary, and randomizing the virtual placement of > >> > the kernel itself, the modules and the linear region based on entropy > >> > supplied by the bootloader in the /chosen/kaslr-seed DT property. > >> > > >> > Changes since v4: > >> > - add randomization of the linear region, i.e., if the linear region is > >> > substantially larger than the space spanned by RAM, the mapping of RAM > >> > is moved to a random offset inside the linear region. > >> > - dropped the CRC check in kaslr_early_init(), since the only code that may > >> > modify .data through __fixmap_remap_fdt() is instrumentation that should > >> > deal with that correctly (For instance, the branch profiling records taken > >> > branches in structs allocated in .data, and these counts will not be reset > >> > to 0 between the first and the second call to __mmap_switched()) > >> > - add Mark's ack to patch #4 > >> > > >> > >> NOTE: I have omitted the relative kallsyms and relative extable > >> patches, since they already queued in akpm's tree. However, while the > >> kallsyms patch is merely an optimization, the extable patches are in > >> fact required for correct operation, since the build time sorting does > >> not work on absolute extables (this is due to the fact that the > >> resolution of the relocations is deferred until runtime, and so the > >> extable addresses are all zero at sorting time) > >> > >> http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch > >> http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch > > > > I'm still trying to get my head around how we merge those. Since I > > assume akpm will push them during the merging window, part of your code > > cannot be tested before. > > Actually, my original idea was for akpm to take them as a late merge > after rebasing to -rc1, since they touch a variety of architectures, > but I am not sure if that came across. > > You could always take the series through your tree instead, I guess? They all have acks from maintainers, so that's an option. > > Can we deselect CONFIG_BUILDTIME_EXTABLE_SORT temporarily while we use > > absolute extable addresses? We patch them at boot-time and sort them > > at run-time. Once the above patches go in, we can revert to build-time > > extable sorting. > > I suppose that would be possible, but I simply haven't tried. I > noticed that ppc does not use build time extable sorting, that is why > they don't need to scripts/extable patch while they do use PIE > binaries. I did a quick check with: and it seems that extable entries end up in the relocation symbols but I haven't fully checked the patching/sorting yet (it will probably be on Monday). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -22,7 +22,7 @@ config ARM64 select ARM_GIC_V3 select ARM_GIC_V3_ITS if PCI_MSI select ARM_PSCI_FW - select BUILDTIME_EXTABLE_SORT + select BUILDTIME_EXTABLE_SORT if !RELOCATABLE select CLONE_BACKWARDS select COMMON_CLK select CPU_PM if (SUSPEND || CPU_IDLE)