From nobody Wed Dec 17 18:05:39 2025 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (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 6D04F1D63EE for ; Thu, 16 Jan 2025 08:46:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737017168; cv=none; b=RGc3Sy+HkhYOZ6cj8RQNVjURRIhz5UPgcSvMG3aaIlFQ9TR3KgSdADEKfsjea+ejshkdC0vACwti/o0BEhfcm6+BVQQQJ2LLrjRIeU9m7o8FAonlArbJmyHH7dXwxDp2xpuIXFNxX5+fT7fukS2xgrXKz44ZOtTVD2u+k7dXDR0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737017168; c=relaxed/simple; bh=RnNHQNv9kB3kJ2am9B8ld8ft13Sf8gJDWi+AxfEF5t4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mSUgDyEA+oDqaBWBEU0BLzW2vEOh8OxCyDHSmOPWf8bIAOwpDi2CXy7n8VFUoWPfjcqFx+nGiuqlPVfarJqQrGiatQmuhNmZCK0i4U244ixyXmYyCZc30hGHpkcfFSH5cD9F958AEMK7M9an08wBIe1q9FY5PIwJp5wlGM4Izig= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4YYc0f72TMz20nyY; Thu, 16 Jan 2025 16:46:26 +0800 (CST) Received: from kwepemd200025.china.huawei.com (unknown [7.221.188.181]) by mail.maildlp.com (Postfix) with ESMTPS id BDAFE180044; Thu, 16 Jan 2025 16:46:02 +0800 (CST) Received: from Linux-SUSE12SP5.huawei.com (10.67.136.247) by kwepemd200025.china.huawei.com (7.221.188.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 16 Jan 2025 16:46:02 +0800 From: pangliyuan To: , , , , , , , , , CC: , , Subject: [RESEND PATCH] powerpc/kprobes: don't save r13 register in kprobe context Date: Thu, 16 Jan 2025 16:45:39 +0800 Message-ID: <20250116084539.58847-1-pangliyuan1@huawei.com> X-Mailer: git-send-email 2.12.3 In-Reply-To: <20241209091039.72786-1-pangliyuan1@huawei.com> References: <20241209091039.72786-1-pangliyuan1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemd200025.china.huawei.com (7.221.188.181) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When CONFIG_STACKPROTECTOR_STRONG is enabled and FTRACE is disabled on powerpc64, repeatedly triggering the kprobe process may cause stack check failures and panic. Case: There is a kprobe(do nothing in handler) attached to the "shmem_get_inode", and a process A is creating file on tmpfs. CPU0 A |r13 =3D paca_ptrs[0], paca_ptrs[0]->canary=3DA->stack_canary |touch a file on tmpfs |shmem_mknod(): | load A's canary through r13 and stored it in A's stack | shmem_get_inode(): | enter kprobe first | optinsn_slot(): | stored r13 (paca_ptrs[0]) in stack ...... =3D=3D> schedule, B run on CPU0, A run on CPU1 CPU0 B |r13 =3D paca_ptrs[0], paca_ptrs[0]->canary=3DB->stack_canary |do something... CPU1 A | r13 =3D paca_ptrs[1], paca_ptrs[1]->canary=3DA->stack_canary | about to leave 'optinsn_slot', restore r13 from A's stack | r13 =3D paca_ptrs[0], paca_ptrs[0]->canary=3DB->stack_canary | leave optinsn_slot, back to shmem_get_inode | leave shmem_get_inode, back to shmem_mknod | do canary check in shmem_mknod, but canary stored in A's stack (A's canary) doesn't match the canary loaded through r13 (B's canary), so panic When A(on CPU0) entring optinsn_slot, it stored r13(paca_ptrs[0]) in stack, then A is scheduled to CPU1 and restore r13 from A's stack when leaving 'optinsn_slot'. Now A is running on CPU1 but r13 point to CPU0's paca_ptrs[0], at this time paca_ptrs[0]->__current points to another process B, which cause A use B's canary to do stack check and panic. This can be simply fixed by not saving and restoring the r13 register, because on powerpc64, r13 is a special register that reserved to point to the current process, no need to restore the outdated r13 if scheduled had happened. Fixes: 51c9c0843993 ("powerpc/kprobes: Implement Optprobes") Signed-off-by: pangliyuan --- arch/powerpc/kernel/optprobes_head.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/optprobes_head.S b/arch/powerpc/kernel/opt= probes_head.S index 35932f45fb4e..bf0d77e62ba8 100644 --- a/arch/powerpc/kernel/optprobes_head.S +++ b/arch/powerpc/kernel/optprobes_head.S @@ -10,12 +10,12 @@ #include =20 #ifdef CONFIG_PPC64 -#define SAVE_30GPRS(base) SAVE_GPRS(2, 31, base) -#define REST_30GPRS(base) REST_GPRS(2, 31, base) +#define SAVE_NEEDED_GPRS(base) SAVE_GPRS(2, 12, base); SAVE_GPRS(14, 31, b= ase) +#define REST_NEEDED_GPRS(base) REST_GPRS(2, 12, base); REST_GPRS(14, 31, b= ase) #define TEMPLATE_FOR_IMM_LOAD_INSNS nop; nop; nop; nop; nop #else -#define SAVE_30GPRS(base) stmw r2, GPR2(base) -#define REST_30GPRS(base) lmw r2, GPR2(base) +#define SAVE_NEEDED_GPRS(base) stmw r2, GPR2(base) +#define REST_NEEDED_GPRS(base) lmw r2, GPR2(base) #define TEMPLATE_FOR_IMM_LOAD_INSNS nop; nop; nop #endif =20 @@ -45,7 +45,7 @@ optprobe_template_entry: /* Save the previous SP into stack */ addi r0,r1,INT_FRAME_SIZE PPC_STL r0,GPR1(r1) - SAVE_30GPRS(r1) + SAVE_NEEDED_GPRS(r1) /* Save SPRS */ mfmsr r5 PPC_STL r5,_MSR(r1) @@ -123,7 +123,7 @@ optprobe_template_call_emulate: PPC_LL r5,_CCR(r1) mtcr r5 REST_GPR(0,r1) - REST_30GPRS(r1) + REST_NEEDED_GPRS(r1) /* Restore the previous SP */ addi r1,r1,INT_FRAME_SIZE =20 --=20 2.37.7