Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1525437ybm; Thu, 23 May 2019 02:31:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5In14ANq+wJa/3iR4s8qVQHJwq4eX0s7Ouz+R1+l9U30EeuNnh4zsEup95pEdw4e9ScHp X-Received: by 2002:a63:4852:: with SMTP id x18mr82989620pgk.14.1558603865205; Thu, 23 May 2019 02:31:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558603865; cv=none; d=google.com; s=arc-20160816; b=LFNicRJy56SHGJ9oVKS+TFzjRw+cOn6VkmD9nqI77KLiOytB4mDdWJ+EgLq1Lcu35R Mokpc5+4XB6GzbT5tarLEGORJ0XGyfrxP0NwIF+N8yT50qGZlwW+GFvy9487uhp6y+Ak 8jytkUwqZOXQjbqRsIV80HwSS9aKPQ6cN89n5+GiZwsjIokrK3xCIFjrDpGvLXRKgqay iG1cisnafRZVs5dB3tngZXOWuWacGVA6wbXJNZ8/3In01v7+uhEYJ/c0JcJEmwmwjbcx YfI/OaXtk4llLrsOyv8Kkd4qYGXZhGlF2Tb8UzcPajOzkOiobt6q7442vLLZn7PpKduJ 5NZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=5n/1S4sLZhyrU5v0H9JXsaMRhDDf3+atFuD/l1tKuaA=; b=CXDVWAm59XME07vxFHfBV0pWklKlpj+jJwsD8Ky0HamlGw4BIOAx1uD4/5wJsW2L/s ns2A7X56c4p0VaQUZX0f9VCZ9t/NIthEDBj1wRWTEg2BzE8AIb6rDC0Wz7DmurF5G17a 9+5siwpXl8eO8Mh+QKVAHGKaLIPHi9GMTsHV+DKtPq3vdDEi5MSCwH13+B6Gh1Ywyj0V s5PwEI/ecwnCkrxKbAmJ5pq21DjnfI5oyG6MIGkc2WHJnmUBd3spV6F+JK88zqnn7WRS Cg2UtxkcOdLBL5za4JcEC1tXyMnNuqRnRK3MHl5vGAlDQ4c+XxUnjZ1piHcu1IitOT6p qMWg== ARC-Authentication-Results: i=1; mx.google.com; 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 j1si30212070pld.399.2019.05.23.02.30.50; Thu, 23 May 2019 02:31:05 -0700 (PDT) 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; 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 S1730341AbfEWJ3n (ORCPT + 99 others); Thu, 23 May 2019 05:29:43 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41362 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726309AbfEWJ3m (ORCPT ); Thu, 23 May 2019 05:29:42 -0400 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 81220341; Thu, 23 May 2019 02:29:42 -0700 (PDT) Received: from [10.1.39.23] (unknown [10.1.39.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7F9213F718; Thu, 23 May 2019 02:29:40 -0700 (PDT) Subject: Re: [PATCH] module/ksymtab: use 64-bit relative reference for target symbol To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, marc.zyngier@arm.com, james.morse@arm.com, guillaume.gardet@arm.com, mark.rutland@arm.com, mingo@kernel.org, jeyu@kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, arnd@arndb.de, x86@kernel.org References: <20190522150239.19314-1-ard.biesheuvel@arm.com> <293c9d0f-dc14-1413-e4b4-4299f0acfb9e@arm.com> <20190523091811.GA26646@fuggles.cambridge.arm.com> From: Ard Biesheuvel Message-ID: <907a9681-cd1d-3326-e3dd-5f6965497720@arm.com> Date: Thu, 23 May 2019 10:29:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190523091811.GA26646@fuggles.cambridge.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/23/19 10:18 AM, Will Deacon wrote: > On Thu, May 23, 2019 at 09:41:40AM +0100, Ard Biesheuvel wrote: >> >> >> On 5/22/19 5:28 PM, Ard Biesheuvel wrote: >>> >>> >>> On 5/22/19 4:02 PM, Ard Biesheuvel wrote: >>>> The following commit >>>> >>>>    7290d5809571 ("module: use relative references for __ksymtab entries") >>>> >>>> updated the ksymtab handling of some KASLR capable architectures >>>> so that ksymtab entries are emitted as pairs of 32-bit relative >>>> references. This reduces the size of the entries, but more >>>> importantly, it gets rid of statically assigned absolute >>>> addresses, which require fixing up at boot time if the kernel >>>> is self relocating (which takes a 24 byte RELA entry for each >>>> member of the ksymtab struct). >>>> >>>> Since ksymtab entries are always part of the same module as the >>>> symbol they export (or of the core kernel), it was assumed at the >>>> time that a 32-bit relative reference is always sufficient to >>>> capture the offset between a ksymtab entry and its target symbol. >>>> >>>> Unfortunately, this is not always true: in the case of per-CPU >>>> variables, a per-CPU variable's base address (which usually differs >>>> from the actual address of any of its per-CPU copies) could be at >>>> an arbitrary offset from the ksymtab entry, and so it may be out >>>> of range for a 32-bit relative reference. >>>> >> >> (Apologies for the 3-act monologue) > > Exposition, development and recapitulation ;) > >> This turns out to be incorrect. The symbol address of per-CPU variables >> exported by modules is always in the vicinity of __per_cpu_start, and so it >> is simply a matter of making sure that the core kernel is in range for >> module ksymtab entries containing 32-bit relative references. >> >> When running the arm64 with kaslr enabled, we currently randomize the module >> space based on the range of ADRP/ADD instruction pairs, which have a -/+ 4 >> GB range rather than the -/+ 2 GB range of 32-bit place relative data >> relocations. So we can fix this by simply reducing the randomization window >> to 2 GB. > > Makes sense. Do you see the need for an option to disable PREL relocs > altogether in case somebody wants the additional randomization range? > No, not really. To be honest, I don't think CONFIG_RANDOMIZE_MODULE_REGION_FULL is that useful to begin with, and the only reason we enabled it by default at the time was to ensure that the PLT code got some coverage after we introduced it.