Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp617434ybi; Fri, 14 Jun 2019 00:04:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzALZ3MrifW2SsJLg46LkjdnNFJlJyGOx8PBD4wnquDHq/9pSeKK8oRK1nhaCYajDl6NJ27 X-Received: by 2002:aa7:9115:: with SMTP id 21mr94425896pfh.14.1560495849697; Fri, 14 Jun 2019 00:04:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560495849; cv=none; d=google.com; s=arc-20160816; b=H1Pkac3yp/6K5m3k2s24Vc3MXnpdciCSi7ZyAvn0gFB5EaGf7bR1buGVBfDf3RYXEC dIm/VvQSCoZfv/3Wk2yM30wNkSL+b1+uOQLiKKqqmstObhgSaNQLzVEP1GdavyBYrqpA hdoi+1qan7X/Fi2bi3QE/4ISspxBzBeZ74AeORZgNO5lp5Tjso8jG4LS6Ggr8GsocNdO 0qP+mzazSBEd6uSZ9mKqVzf/UQu4dIT++sM7vjBkfuo/PXMvBFTF+wsBfaXvIlMol4Vz /JOhP4PwFv9eHPgsILOaIA2UVBdkazH4DzGIzomk0nT1p69DYS3J8TNQvKJyClHiQDm7 /B7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/e9SMaz1f2hGhr+Y7ePFxQlAt1pAXhkHDxZGScVnsP0=; b=NdQV9DdCMWz34zIMjBcTVYlj1VeWRwU9uBtcrl0I5Ki4+StC0ebTxlJgTs1gJENQbp BsevgIzVt9tRiWmJelQtUXTjHT+9MkQQ3V6oCwI4dQr228Q36n6Dl8/N26RLj2fXge5O uk+lK7vOaNAEmsqg/UkVo2x52OKRUBDurpzjzMSS3iDqLKbkkWFDt5oihMmW911HJq/n GS5kg63UtpmYFJuOJpGFLm5ofVq+f1sFAPwgOAqUM+FiCR8MTguyNI71StBbLbHRTTq2 QvEgTBdg2rWemk+RFvOpBSfXPo2VuP0PLjFLIIGIASrATqXjoMXN0TrYL+/lKTobIND6 We2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VeS3CU0G; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d36si1527353pla.113.2019.06.14.00.03.53; Fri, 14 Jun 2019 00:04:09 -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; dkim=pass header.i=@linaro.org header.s=google header.b=VeS3CU0G; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726255AbfFNHDD (ORCPT + 99 others); Fri, 14 Jun 2019 03:03:03 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:46807 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfFNHDC (ORCPT ); Fri, 14 Jun 2019 03:03:02 -0400 Received: by mail-io1-f68.google.com with SMTP id i10so3412465iol.13 for ; Fri, 14 Jun 2019 00:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/e9SMaz1f2hGhr+Y7ePFxQlAt1pAXhkHDxZGScVnsP0=; b=VeS3CU0GVfEu7mUzCPUp6p8noRpmTbKdsRVKGt5bZ4jZnOSQhpuqS+ezrT+pak6Dc4 wCCOwBgDRwBJPwMdJdXl9ISTJZgvJVhwnxtLKKyovc07NM/cjyPDPQsrrEtSfVvR1bDA IAuZZgXXVBUlis5movc1J9Nxn7jJoc9wK1V2yrB0jG32i+tZ9ii9CKS4mszok4ieLBvk Rk1EBY/iZaFkhvgzNS3AsIW2B6tVwziphPKYyJbMNQQs5ynzTSn874Hu8rrAePxMF/c4 UpbX4ImEi2jtEVWL0lAhtd8KupAEgjqL/1GHGIjqMO0WgUSDYfVw0w6ecfBdH+3Par36 fWYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/e9SMaz1f2hGhr+Y7ePFxQlAt1pAXhkHDxZGScVnsP0=; b=CQrirEk94jY+YxAqB5UbliRK8dtCgqCu3R4CKit99q2467hakdBgH/24/6hIh0sXEj jsp6eXMgsoXRH9bJ2wl5e6WlIG7k/sML0CDTr2aAfjL6MF284z9gMlrNxEbV+4t/KleK XdBqLtUqcNdmk8r9W6Obq/bzpXsbIbKjnL/muhy8sIPS0pYx2Fx9hna4Gqu+Hq+KrpDv a5J2U9bTEASAIFK4JUgmN7NpyFIJUW2+Kp2OpSIcM6forXmbdqy2ghF2x1ryq44oeAcX JKYMikW4H9+Y7k/S039b2FQ32tc2mYvfJx8Dqf3E/1Pdvw93lLtGRCF45T2iEou5WOXu vsxQ== X-Gm-Message-State: APjAAAVPxHiNP3Zt5fFaAlefv8gs9sgGvLHHUFKrXPFb2pM0OFqA6Tvm 0QzY3/nC5nSvRCK9eRGuTl4rSL8TGfbLpQt2Ag5oFg== X-Received: by 2002:a5e:820a:: with SMTP id l10mr5570290iom.283.1560495781891; Fri, 14 Jun 2019 00:03:01 -0700 (PDT) MIME-Version: 1.0 References: <20190614025932.533-1-f.fainelli@gmail.com> In-Reply-To: <20190614025932.533-1-f.fainelli@gmail.com> From: Ard Biesheuvel Date: Fri, 14 Jun 2019 09:02:49 +0200 Message-ID: Subject: Re: [PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS To: Florian Fainelli Cc: linux-arm-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Catalin Marinas , Will Deacon , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , open list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 Jun 2019 at 04:59, Florian Fainelli wrote: > > Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people > might have very big modules spilling out of the dedicated module area > into vmalloc. Help text is copied from the ARM 32-bit counterpart. > > Signed-off-by: Florian Fainelli > --- > arch/arm64/Kconfig | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 697ea0510729..36befe987b73 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1418,8 +1418,20 @@ config ARM64_SVE > KVM in the same kernel image. > > config ARM64_MODULE_PLTS > - bool > + bool "Use PLTs to allow module memory to spill over into vmalloc area" > select HAVE_MOD_ARCH_SPECIFIC > + help > + Allocate PLTs when loading modules so that jumps and calls whose > + targets are too far away for their relative offsets to be encoded > + in the instructions themselves can be bounced via veneers in the > + module's PLT. This allows modules to be allocated in the generic > + vmalloc area after the dedicated module memory area has been > + exhausted. The modules will use slightly more memory, but after > + rounding up to page size, the actual memory footprint is usually > + the same. > + > + Disabling this is usually safe for small single-platform > + configurations. If unsure, say y. > I don't mind adding this, but it makes sense to add an explanation why KASLR enables this. E.g., """ When running with address space randomization (KASLR), the module region itself may be too far away for ordinary relative jumps and calls, and so in that case, module PLTs are required and cannot be disabled. """ > config ARM64_PSEUDO_NMI > bool "Support for NMI-like interrupts" > -- > 2.17.1 >