From nobody Sat Feb 7 08:07:33 2026 Received: from relay.smtp-ext.broadcom.com (saphodev.broadcom.com [192.19.144.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39B5E18732E; Thu, 9 Jan 2025 17:03:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.19.144.205 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736442218; cv=none; b=b/wxlrthCpaKsNgpohB3dW0nQ/Wa92/2yl7dtKMwW0e3n4Q0yeOEXdH1WsKUSDsjGRcyDgUT61iKz3yYgWBWz88SOAmnZRalkWGKn7Wp5+AUA3xo2UcYbQkGTmYCRtRaJyL4HhlEbTmWecoqjp/Tdv1AgDKU1DsCym6fHtzXJJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736442218; c=relaxed/simple; bh=SUejWQaCCQ6UOnlEIF8Y+gc/yElELSYPKQtYJBlFtf4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=hzwUyPYchO3xlgwGGRSzKJ69kCFGW5Pc7+u6vTYcxpSGWsCeFwEuuLKlBbzhagFE5Ur7GGr7l/G6uW+VQPsGSjPF24mBxGeTA7Ackcr113x/zPNgEJtG4+3PP+iERcR8QT8J6dSzd7k+YQJKErJ+YxoSHOMpcUmGFOFdqvBVzNQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=kV7xB6JJ; arc=none smtp.client-ip=192.19.144.205 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="kV7xB6JJ" Received: from mail-lvn-it-01.lvn.broadcom.net (mail-lvn-it-01.lvn.broadcom.net [10.36.132.253]) by relay.smtp-ext.broadcom.com (Postfix) with ESMTP id CE6ACC0000E8; Thu, 9 Jan 2025 08:54:22 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com CE6ACC0000E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1736441662; bh=SUejWQaCCQ6UOnlEIF8Y+gc/yElELSYPKQtYJBlFtf4=; h=From:To:Cc:Subject:Date:From; b=kV7xB6JJuMPSScCf/QhQbMLjsitXPYL4hv+kABwyIm1cbIjg6l+/kb1Vd092YWPb8 Vu+vKfwY8tJ3QhT8fb20fa/174LzSo4n2E8OaYlJYXBOg7gX+BRfolIyu+RnbqNDcp 5yqNNviGmgn9Xoq8WBKv7s81grk41SYj0QZypt/s= Received: from fainelli-desktop.igp.broadcom.net (fainelli-desktop.dhcp.broadcom.net [10.67.48.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail-lvn-it-01.lvn.broadcom.net (Postfix) with ESMTPSA id 63D2418041CAC6; Thu, 9 Jan 2025 08:54:22 -0800 (PST) From: Florian Fainelli To: stable@vger.kernel.org Cc: Ard Biesheuvel , Anshuman Khandual , Will Deacon , Steven Price , Robin Murphy , Catalin Marinas , Florian Fainelli , Baruch Siach , Petr Tesarik , Joey Gouly , "Mike Rapoport (IBM)" , Baoquan He , Yang Shi , linux-arm-kernel@lists.infradead.org (moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)), linux-kernel@vger.kernel.org (open list) Subject: [PATCH stable 5.4] arm64: mm: account for hotplug memory when randomizing the linear region Date: Thu, 9 Jan 2025 08:54:16 -0800 Message-ID: <20250109165419.1623683-1-florian.fainelli@broadcom.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel commit 97d6786e0669daa5c2f2d07a057f574e849dfd3e upstream As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed. So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region. Signed-off-by: Ard Biesheuvel Cc: Anshuman Khandual Cc: Will Deacon Cc: Steven Price Cc: Robin Murphy Link: https://lore.kernel.org/r/20201014081857.3288-1-ardb@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Florian Fainelli --- arch/arm64/mm/init.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index cbcac03c0e0d..a6034645d6f7 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -392,15 +392,18 @@ void __init arm64_memblock_init(void) =20 if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) { extern u16 memstart_offset_seed; - u64 range =3D linear_region_size - - (memblock_end_of_DRAM() - memblock_start_of_DRAM()); + u64 mmfr0 =3D read_cpuid(ID_AA64MMFR0_EL1); + int parange =3D cpuid_feature_extract_unsigned_field( + mmfr0, ID_AA64MMFR0_PARANGE_SHIFT); + s64 range =3D linear_region_size - + BIT(id_aa64mmfr0_parange_to_phys_shift(parange)); =20 /* * If the size of the linear region exceeds, by a sufficient - * margin, the size of the region that the available physical - * memory spans, randomize the linear region as well. + * margin, the size of the region that the physical memory can + * span, randomize the linear region as well. */ - if (memstart_offset_seed > 0 && range >=3D ARM64_MEMSTART_ALIGN) { + if (memstart_offset_seed > 0 && range >=3D (s64)ARM64_MEMSTART_ALIGN) { range /=3D ARM64_MEMSTART_ALIGN; memstart_addr -=3D ARM64_MEMSTART_ALIGN * ((range * memstart_offset_seed) >> 16); --=20 2.43.0