From patchwork Tue May 30 11:03:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 13259749 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 77820C7EE29 for ; Tue, 30 May 2023 11:04:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=zZRCephIn8b+SypIFb/LJXB+CkznG3b1GuK+JEPV9Dw=; b=iuBcxRwrnp6Iss Ph/rZesVipUImHTQ3BhDBDVziu7+xhJGqPV1rWxbKouFitImutguBxXB6a3CGGAQ8xKeFRIykm8Lx Hi0e88mnTyYDnQF9B/+mrnE2lepQYORawwvfwS9UAeIMjpWVfsfdtZ1q/sJ6QXkFS5rhK82d91Mgi wBrS0Z42Ioc5fkJamNRy2qc8kAR0qPZAmfavBACGfKsBv5lB4nQgR6TGiO2dGG+LFtWgPCxBUyMU0 vyqUj1xJcjN9cZC2dlk5vrwJj4JrgVbgDRQPoDyA/FtSMLAJHP1OS3VldfyDzfr3WcvdDuS+gQI/Y Wm+adzcoqN6phP4FNeNQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q3x8e-00DZ6v-0G; Tue, 30 May 2023 11:03:40 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q3x8b-00DZ5p-0N for linux-arm-kernel@lists.infradead.org; Tue, 30 May 2023 11:03:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 416132F4; Tue, 30 May 2023 04:04:20 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 817C43F67D; Tue, 30 May 2023 04:03:33 -0700 (PDT) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Cc: akpm@linux-foundation.org, andreyknvl@google.com, ardb@kernel.org, catalin.marinas@arm.com, dvyukov@google.com, glider@google.com, mark.rutland@arm.com, ryabinin.a.a@gmail.com, sdonthineni@nvidia.com, will@kernel.org Subject: [PATCH v3 0/6] arm64: module: improve module VA range selection Date: Tue, 30 May 2023 12:03:22 +0100 Message-Id: <20230530110328.2213762-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230530_040337_204870_A3AC7496 X-CRM114-Status: GOOD ( 13.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org This series (based on v6.4-rc3) aims to make arm64's module allocation code more robust. To that end: * Redundant code for KASAN && !KASAN_VMALLOC is removed, as this combination is no longer possible. * Module PLT support is mandated, always allowing for the use of a 2G module region. Practically speaking, this is already the case for almost all users as module PLT support is mandated by both KASLR (which most distros including Android, enable this), and by the workaround for ARM erratum 843419 (required by Cortex-A53). * The module VA region selection is moved to module.c, making it self-contained and easier to follow. * The default module VA region is expanded to 2G. This ensures that there is sufficient space for the full region using PLTs even when KASLR is disabled or no seed provided. * The module VA range init code is updated to log when the kernel is too large to support the use of a 128M or 2G module region, to enable debugging of these cases. Contemporary kernels built with debug options can be bigger than 128M, and a kernel bigger than 2G is unlikely but theoretically possible. Adding this logging should help to debug or filter away reports for such cases. This should allow for loading of very large modules, as Shanker reported was an issue: https://lore.kernel.org/linux-arm-kernel/20230326170756.3021936-1-sdonthineni@nvidia.com/ https://lore.kernel.org/linux-arm-kernel/20230330140437.984211-1-sdonthineni@nvidia.com/ ... and as Ard had an alternative series for: https://lore.kernel.org/linux-arm-kernel/20230404135437.2744866-1-ardb@kernel.org/ Since v1 [1]: * Log the number of pages in range * Remove unused kasan_mod_shadow_end * Only randomize when kaslr_enabled() * Simplify control-flow Since v2 [2]: * Apply Ard's Reviewed-by tags * Fix typos * Rebave to v6.4-rc3 (trivial) [1] https://lore.kernel.org/linux-arm-kernel/20230509111451.4184972-1-mark.rutland@arm.com/ [2] https://lore.kernel.org/linux-arm-kernel/20230512152210.3072475-1-mark.rutland@arm.com/ Thanks, Mark. Mark Rutland (6): arm64: module: remove old !KASAN_VMALLOC logic arm64: kasan: remove !KASAN_VMALLOC remnants arm64: kaslr: split kaslr/module initialization arm64: module: move module randomization to module.c arm64: module: mandate MODULE_PLTS arm64: module: rework module VA range selection Documentation/arm64/memory.rst | 8 +- arch/arm64/Kconfig | 28 +---- arch/arm64/include/asm/memory.h | 16 +-- arch/arm64/include/asm/module.h | 8 -- arch/arm64/include/asm/module.lds.h | 2 - arch/arm64/kernel/Makefile | 3 +- arch/arm64/kernel/ftrace.c | 8 +- arch/arm64/kernel/kaslr.c | 83 +++------------ arch/arm64/kernel/module.c | 159 +++++++++++++++++++++------- arch/arm64/kernel/setup.c | 2 + arch/arm64/mm/kasan_init.c | 17 +-- 11 files changed, 159 insertions(+), 175 deletions(-) Tested-by: Shanker Donthineni