lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Jul 2021 16:55:03 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Caleb Connolly <caleb@...nolly.tech>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Sasha Levin <sashal@...nel.org>
Subject: [PATCH 5.12 241/292] arm64: dts: qcom: sdm845-oneplus-common: guard rmtfs-mem

From: Caleb Connolly <caleb@...nolly.tech>

[ Upstream commit e60fd5ac1f6851be5b2c042b39584bfcf8a66f57 ]

The rmtfs_mem region is a weird one, downstream allocates it
dynamically, and supports a "qcom,guard-memory" property which when set
will reserve 4k above and below the rmtfs memory.

A common from qcom 4.9 kernel msm_sharedmem driver:

/*
 * If guard_memory is set, then the shared memory region
 * will be guarded by SZ_4K at the start and at the end.
 * This is needed to overcome the XPU limitation on few
 * MSM HW, so as to make this memory not contiguous with
 * other allocations that may possibly happen from other
 * clients in the system.
*/

When the kernel tries to touch memory that is too close the
rmtfs region it may cause an XPU violation. Such is the case on the
OnePlus 6 where random crashes would occur usually after boot.

Reserve 4k above and below the rmtfs_mem to avoid hitting these XPU
Violations.

This doesn't entirely solve the random crashes on the OnePlus 6/6T but
it does seem to prevent the ones which happen shortly after modem
bringup.

Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices")
Signed-off-by: Caleb Connolly <caleb@...nolly.tech>
Link: https://lore.kernel.org/r/20210502014146.85642-4-caleb@connolly.tech
Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 8f617f7b6d34..f712771df0c7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -46,6 +46,14 @@
 	};
 
 	reserved-memory {
+		/* The rmtfs_mem needs to be guarded due to "XPU limitations"
+		 * it is otherwise possible for an allocation adjacent to the
+		 * rmtfs_mem region to trigger an XPU violation, causing a crash.
+		 */
+		rmtfs_lower_guard: memory@...00000 {
+			no-map;
+			reg = <0 0xf5b00000 0 0x1000>;
+		};
 		/*
 		 * The rmtfs memory region in downstream is 'dynamically allocated'
 		 * but given the same address every time. Hard code it as this address is
@@ -59,6 +67,10 @@
 			qcom,client-id = <1>;
 			qcom,vmid = <15>;
 		};
+		rmtfs_upper_guard: memory@...01000 {
+			no-map;
+			reg = <0 0xf5d01000 0 0x2000>;
+		};
 
 		/*
 		 * It seems like reserving the old rmtfs_mem region is also needed to prevent
-- 
2.30.2



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ