From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 800081A2C04; Sun, 4 May 2025 23:32:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; cv=none; b=oHf7TbrKxblSGq561G01P9WCro1aPjnKDG5wxbHBdCZ8g/lFtgHExFQ19rnvaMjwlWOJH//rZ7S98f/E/b/3BZG/QncHh9ps2hCGK8ECORcridxRnwviU90dGCyc/VHgZgfe0R8o/9E8cFF3k7LjKHhsvjMhvRhp4hVahRnbZC8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; c=relaxed/simple; bh=J7s8OIjWZ4YaXdyjZT+i+XxgiSVNcChkoHdKGE5I9qI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PwIghHeXXPHPl7d57exczXvPb9xRaJIE4OKm7cEH/fmlz6fe8kFoMs5D7b/L17eTCc5eCKeDCVvTQym3ArMm9696QeRhfggqX5D2ej8awLQVNN2ZiiBrrXPfOLHwvH42TE8lfSBiopXfBktZmG/2UNMYMfmeKrWcOodBJqQxfiU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 4825B1063; Sun, 4 May 2025 16:32:07 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F137B3F58B; Sun, 4 May 2025 16:32:15 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 1/7] arm64/gcs: task_gcs_el0_enable() should use passed task Date: Sun, 4 May 2025 18:31:57 -0500 Message-ID: <20250504233203.616587-2-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" Mark Rutland noticed that the task parameter is ignored and 'current' is being used instead. Since this is usually what its passed, it hasn't yet been causing problems but likely will as the code gets more testing. But, once this is fixed, it creates a new bug in copy_thread_gcs() since the gcs_el_mode isn't yet set for the task before its being checked. Move gcs_alloc_thread_stack() after the new task's gcs_el0_mode initialization to avoid this. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Signed-off-by: Jeremy Linton Reviewed-by: Mark Brown --- arch/arm64/include/asm/gcs.h | 2 +- arch/arm64/kernel/process.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/gcs.h b/arch/arm64/include/asm/gcs.h index f50660603ecf..5bc432234d3a 100644 --- a/arch/arm64/include/asm/gcs.h +++ b/arch/arm64/include/asm/gcs.h @@ -58,7 +58,7 @@ static inline u64 gcsss2(void) =20 static inline bool task_gcs_el0_enabled(struct task_struct *task) { - return current->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE; + return task->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE; } =20 void gcs_set_el0_mode(struct task_struct *task); diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 42faebb7b712..68b7021cda77 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -305,13 +305,13 @@ static int copy_thread_gcs(struct task_struct *p, p->thread.gcs_base =3D 0; p->thread.gcs_size =3D 0; =20 + p->thread.gcs_el0_mode =3D current->thread.gcs_el0_mode; + p->thread.gcs_el0_locked =3D current->thread.gcs_el0_locked; + gcs =3D gcs_alloc_thread_stack(p, args); if (IS_ERR_VALUE(gcs)) return PTR_ERR((void *)gcs); =20 - p->thread.gcs_el0_mode =3D current->thread.gcs_el0_mode; - p->thread.gcs_el0_locked =3D current->thread.gcs_el0_locked; - return 0; } =20 --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 861F124E4B4; Sun, 4 May 2025 23:32:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401546; cv=none; b=Hro83FrfgtGAYE9vyomGrxfyGf3SS+i8VlYTSmEDfbRil2OJZhAqnmE6Qfbp/60ipOiiHx6K3JQ0PLEvSXizDjkJQLJ3Z35c0dtVux4DyfWzHfxA+Vl66ssyczY12MOYlBVJ2keaufiBFuWqcH0ao/NSBEzRiyWhIdazj91+bq8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401546; c=relaxed/simple; bh=sqMQDzvFmXnESvEW65BX+Gydje+6XtdWN5A4O+i9z+g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kt9QHdE+n+LakEnzgDll7m3eRU4AbFzV9MFIMjVYZMqW+BZe9liPFbAIheyHbTAdnsXPY0yPV4q4Rn9PaXy4MblHWthxeMZAQq9spOjntE9iuXzcXouvzEiklcuQsW3eh+qlPY0HZF2gJn8BttFO6n8zslmSlrVHSct3NkHCSts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 8F742175A; Sun, 4 May 2025 16:32:08 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 424C53F58B; Sun, 4 May 2025 16:32:17 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 2/7] arm64: probes: Break ret out from bl/blr Date: Sun, 4 May 2025 18:31:58 -0500 Message-ID: <20250504233203.616587-3-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" Prepare for GCS by breaking RET out into its own function, where it makes more sense to encapsulate the new behavior independent from the branch instructions. Signed-off-by: Jeremy Linton --- arch/arm64/kernel/probes/decode-insn.c | 7 ++++--- arch/arm64/kernel/probes/simulate-insn.c | 10 +++++++++- arch/arm64/kernel/probes/simulate-insn.h | 3 ++- 3 files changed, 15 insertions(+), 5 deletions(-) diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/pro= bes/decode-insn.c index 6438bf62e753..4137cc5ef031 100644 --- a/arch/arm64/kernel/probes/decode-insn.c +++ b/arch/arm64/kernel/probes/decode-insn.c @@ -108,9 +108,10 @@ arm_probe_decode_insn(u32 insn, struct arch_probe_insn= *api) aarch64_insn_is_bl(insn)) { api->handler =3D simulate_b_bl; } else if (aarch64_insn_is_br(insn) || - aarch64_insn_is_blr(insn) || - aarch64_insn_is_ret(insn)) { - api->handler =3D simulate_br_blr_ret; + aarch64_insn_is_blr(insn)) { + api->handler =3D simulate_br_blr; + } else if (aarch64_insn_is_ret(insn)) { + api->handler =3D simulate_ret; } else { /* * Instruction cannot be stepped out-of-line and we don't diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/p= robes/simulate-insn.c index 4c6d2d712fbd..09a0b36122d0 100644 --- a/arch/arm64/kernel/probes/simulate-insn.c +++ b/arch/arm64/kernel/probes/simulate-insn.c @@ -126,7 +126,7 @@ simulate_b_cond(u32 opcode, long addr, struct pt_regs *= regs) } =20 void __kprobes -simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs) +simulate_br_blr(u32 opcode, long addr, struct pt_regs *regs) { int xn =3D (opcode >> 5) & 0x1f; =20 @@ -138,6 +138,14 @@ simulate_br_blr_ret(u32 opcode, long addr, struct pt_r= egs *regs) set_x_reg(regs, 30, addr + 4); } =20 +void __kprobes +simulate_ret(u32 opcode, long addr, struct pt_regs *regs) +{ + int xn =3D (opcode >> 5) & 0x1f; + + instruction_pointer_set(regs, get_x_reg(regs, xn)); +} + void __kprobes simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs) { diff --git a/arch/arm64/kernel/probes/simulate-insn.h b/arch/arm64/kernel/p= robes/simulate-insn.h index efb2803ec943..9e772a292d56 100644 --- a/arch/arm64/kernel/probes/simulate-insn.h +++ b/arch/arm64/kernel/probes/simulate-insn.h @@ -11,7 +11,8 @@ void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs); void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs); void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs); -void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs); +void simulate_br_blr(u32 opcode, long addr, struct pt_regs *regs); +void simulate_ret(u32 opcode, long addr, struct pt_regs *regs); void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs); void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs); void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs); --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2AB6D250C0E; Sun, 4 May 2025 23:32:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401546; cv=none; b=Y+iX0uLZeN9eC5vEDEmRFEKt0d1JjAAVYZSBM6634BeR24iwgTpptpwzphUek/cp0cuWJk8M0MWvLZjn1F+Px/Y/1726WF0tbrmMAGHBSam8y0iaEfCm72ZLEmPmjpWy/seZqjC2ahowV6oTrWX23xVt2Uqf1xHr+/PTmmASMO4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401546; c=relaxed/simple; bh=74l8WQJx+JHUOxctsCLtwn1uQDcdHtUHH9jZWyzig0g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X+ZVVa+FunPljAh0n7ipa+ky5y5kQd9t6zU27ZpJjP1mZc+dDYe3g70U9LcZXrqpBLturhk178aSMRApv+KcQMpgMMsJ3XwuKQfi+VyPFc3DRINAbihWFDCRDEXEe30QEoTHWKPNc3+Rc7xyOREe7nmvRaF8hv6O6O8ZNWBqBw8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 9DF2E1BC0; Sun, 4 May 2025 16:32:09 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 51E533F58B; Sun, 4 May 2025 16:32:18 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 3/7] arm64: uaccess: Add additional userspace GCS accessors Date: Sun, 4 May 2025 18:31:59 -0500 Message-ID: <20250504233203.616587-4-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" Uprobes need more advanced read, push, and pop userspace GCS functionality. Implement those features using the existing gcsstr() and copy_from_user(). Its important to note that GCS pages can be read by normal instructions, but the hardware validates that pages used by GCS specific operations, have a GCS privilege set. We aren't validating this in load_user_gcs because it requires stabilizing the VMA over the read which may fault. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/uaccess.h | 42 ++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uacc= ess.h index 5b91803201ef..34a8b2cc8935 100644 --- a/arch/arm64/include/asm/uaccess.h +++ b/arch/arm64/include/asm/uaccess.h @@ -20,6 +20,7 @@ =20 #include #include +#include #include #include #include @@ -539,6 +540,47 @@ static inline void put_user_gcs(unsigned long val, uns= igned long __user *addr, uaccess_ttbr0_disable(); } =20 +static __always_inline unsigned long __must_check +copy_from_user(void *to, const void __user *from, unsigned long n); + +/* + * Unlike put_user_gcs() above, the use of copy_from_user() may provide + * an opening for non GCS pages to be used to source data. Therefore this + * should only be used in contexts where that is acceptable. + */ +static inline u64 load_user_gcs(unsigned long __user *addr, int *err) +{ + unsigned long ret; + u64 load =3D 0; + + gcsb_dsync(); + ret =3D copy_from_user(&load, addr, sizeof(load)); + if (ret !=3D 0) + *err =3D ret; + return load; +} + +static inline void push_user_gcs(unsigned long val, int *err) +{ + u64 gcspr =3D read_sysreg_s(SYS_GCSPR_EL0); + + gcspr -=3D sizeof(u64); + put_user_gcs(val, (unsigned long __user *)gcspr, err); + if (!*err) + write_sysreg_s(gcspr, SYS_GCSPR_EL0); +} + +static inline u64 pop_user_gcs(int *err) +{ + u64 gcspr =3D read_sysreg_s(SYS_GCSPR_EL0); + u64 read_val; + + read_val =3D load_user_gcs((unsigned long __user *)gcspr, err); + if (!*err) + write_sysreg_s(gcspr + sizeof(u64), SYS_GCSPR_EL0); + + return read_val; +} =20 #endif /* CONFIG_ARM64_GCS */ =20 --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B730919E99E; Sun, 4 May 2025 23:32:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401543; cv=none; b=YlV6mmG3ephLJo+oCE2ux35x1Fs7VZeODeOtXinuR6H8SkdqgsBEce4O9H1OjQMBU4itNoQA2AJWg/UEHVZmMpTbP2i9PtPeVmVz/vgR6LNZLhW3lOv7XhWD1DkGr9dhpvLy7QEsDOcM41F600Qf3j1BIlYWCsWQv2tVuJtjGL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401543; c=relaxed/simple; bh=kLX4GPXdc2MyzorNOoQOdyrhDoXkrR4tpwMTfk7Xp+M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rGXjY9dShE0r6IL4+BN8UGKPYKhpRAZ+vskmAMwuIu+V8wz5LV0Xhf2ypDoHs8CF3eXt6gWQrCWCquMySOmImK89wG3nY7rXPTt9BLtFd+GcbQAoVvJRL4G5dS7LX+pVCz+gZFVtWeKYiy9uHmGoiLp5aRMOsXpc6pHg3qWnrUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 A6D111BCB; Sun, 4 May 2025 16:32:10 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 59B1F3F58B; Sun, 4 May 2025 16:32:19 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 4/7] arm64: probes: Add GCS support to bl/blr/ret Date: Sun, 4 May 2025 18:32:00 -0500 Message-ID: <20250504233203.616587-5-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" The arm64 probe simulation doesn't currently have logic in place to deal with GCS and this results in core dumps if probes are inserted at control flow locations. Fix-up bl, blr and ret to manipulate the shadow stack as needed. While we manipulate and validate the shadow stack correctly, the hardware provides additional security by only allowing GCS operations against pages which are marked to support GCS. For writing there is gcssttr() which enforces this, but there isn't an equivalent for reading. This means that uprobe users should be aware that probing on control flow instructions which require reading the shadow stack (ex: ret) offers lower security guarantees than what is achieved without the uprobe active. Signed-off-by: Jeremy Linton --- arch/arm64/kernel/probes/simulate-insn.c | 35 ++++++++++++++++++++---- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/p= robes/simulate-insn.c index 09a0b36122d0..c75dce7bbe13 100644 --- a/arch/arm64/kernel/probes/simulate-insn.c +++ b/arch/arm64/kernel/probes/simulate-insn.c @@ -13,6 +13,7 @@ #include =20 #include "simulate-insn.h" +#include "asm/gcs.h" =20 #define bbl_displacement(insn) \ sign_extend32(((insn) & 0x3ffffff) << 2, 27) @@ -49,6 +50,20 @@ static inline u32 get_w_reg(struct pt_regs *regs, int re= g) return lower_32_bits(pt_regs_read_reg(regs, reg)); } =20 +static inline void update_lr(struct pt_regs *regs, long addr) +{ + int err =3D 0; + + if (user_mode(regs) && task_gcs_el0_enabled(current)) { + push_user_gcs(addr + 4, &err); + if (err) { + force_sig(SIGSEGV); + return; + } + } + procedure_link_pointer_set(regs, addr + 4); +} + static bool __kprobes check_cbz(u32 opcode, struct pt_regs *regs) { int xn =3D opcode & 0x1f; @@ -107,9 +122,8 @@ simulate_b_bl(u32 opcode, long addr, struct pt_regs *re= gs) { int disp =3D bbl_displacement(opcode); =20 - /* Link register is x30 */ if (opcode & (1 << 31)) - set_x_reg(regs, 30, addr + 4); + update_lr(regs, addr); =20 instruction_pointer_set(regs, addr + disp); } @@ -133,17 +147,26 @@ simulate_br_blr(u32 opcode, long addr, struct pt_regs= *regs) /* update pc first in case we're doing a "blr lr" */ instruction_pointer_set(regs, get_x_reg(regs, xn)); =20 - /* Link register is x30 */ if (((opcode >> 21) & 0x3) =3D=3D 1) - set_x_reg(regs, 30, addr + 4); + update_lr(regs, addr); } =20 void __kprobes simulate_ret(u32 opcode, long addr, struct pt_regs *regs) { - int xn =3D (opcode >> 5) & 0x1f; + u64 ret_addr; + int err =3D 0; + unsigned long lr =3D procedure_link_pointer(regs); =20 - instruction_pointer_set(regs, get_x_reg(regs, xn)); + if (user_mode(regs) && task_gcs_el0_enabled(current)) { + ret_addr =3D pop_user_gcs(&err); + if (err || ret_addr !=3D lr) { + force_sig(SIGSEGV); + return; + } + } + + instruction_pointer_set(regs, lr); } =20 void __kprobes --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A32DA24BD03; Sun, 4 May 2025 23:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401545; cv=none; b=MDzXutOpJBI0D2El2RbJn63+UuRT/Lstouoc6AO6qvcXPsbYQqb1RBKaCjqC+5SJNwrLkSF1GjAaNkpn3F7pze7VJhg8K5Dk/fAwf/DhH8VmxhjN1EQf3Knck3Vy472xDulRE1Kdrg+AU0CHVBUPjk/c7EvWoNLX1IvKM/kTWFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401545; c=relaxed/simple; bh=Oub7b6VLUpd3UWInvg1BovoiCcB2LQjSYbovTmB9cxE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p0eCD+MR684FhqKD4HnmXbtXfgKQb+1z5ZGW5RSnaRGIs32dHHtPThsv3ZvUq8iN9zTmvlVxkaTBFi44VhNJr75vhYEUhPft6X9aB7PD2ToQIqbjkk61YVbgmHgkROJ95K7zGBU8pPNCTMJBH9Iq9YG51gkBFLj1B3G6m/Qmcq4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 B86F51E5E; Sun, 4 May 2025 16:32:11 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 667AB3F58B; Sun, 4 May 2025 16:32:20 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton , Steve Capper Subject: [PATCH v3 5/7] arm64: uprobes: Add GCS support to uretprobes Date: Sun, 4 May 2025 18:32:01 -0500 Message-ID: <20250504233203.616587-6-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" Ret probes work by changing the value in the link register at the probe location to return to the probe rather than the calling routine. Thus the GCS needs to be updated with this address as well. Since its possible to insert probes at locations where the current value of the LR doesn't match the GCS state this needs to be detected and handled in order to maintain the existing no-fault behavior. Co-developed-by: Steve Capper Signed-off-by: Steve Capper (updated to use new gcs accessors, and handle LR/GCS mismatches) Signed-off-by: Jeremy Linton --- arch/arm64/kernel/probes/uprobes.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/arm64/kernel/probes/uprobes.c b/arch/arm64/kernel/probes/= uprobes.c index cb3d05af36e3..5e72409a255a 100644 --- a/arch/arm64/kernel/probes/uprobes.c +++ b/arch/arm64/kernel/probes/uprobes.c @@ -159,11 +159,41 @@ arch_uretprobe_hijack_return_addr(unsigned long tramp= oline_vaddr, struct pt_regs *regs) { unsigned long orig_ret_vaddr; + unsigned long gcs_ret_vaddr; + int err =3D 0; + u64 gcspr; =20 orig_ret_vaddr =3D procedure_link_pointer(regs); + + if (task_gcs_el0_enabled(current)) { + gcspr =3D read_sysreg_s(SYS_GCSPR_EL0); + gcs_ret_vaddr =3D load_user_gcs((unsigned long __user *)gcspr, &err); + if (err) { + force_sig(SIGSEGV); + goto out; + } + /* + * If the LR and GCS entry don't match, then some kind of PAC/control + * flow happened. Likely because the user is attempting to retprobe + * on something that isn't a function boundary or inside a leaf + * function. Explicitly abort this retprobe because it will generate + * a GCS exception. + */ + if (gcs_ret_vaddr !=3D orig_ret_vaddr) { + orig_ret_vaddr =3D -1; + goto out; + } + put_user_gcs(trampoline_vaddr, (unsigned long __user *) gcspr, &err); + if (err) { + force_sig(SIGSEGV); + goto out; + } + } + /* Replace the return addr with trampoline addr */ procedure_link_pointer_set(regs, trampoline_vaddr); =20 +out: return orig_ret_vaddr; } =20 --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 641EA24BBFF; Sun, 4 May 2025 23:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; cv=none; b=EEYCn7iBJ+JQHuAWuTxmk0DE4vynRh04W+iieWkt+h/Z2D9pAz/1xkqTII1fHjPC3qVmr9mRjfuBAyNrrSiA7ZrWZ0TEsXvoPYP1gBx533dRFZVoE6NTqso+e0g5P/ODGM0uT8QSVFLPEW/T+g/FTS1v5e/ckSPx6feBAgvqT98= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; c=relaxed/simple; bh=obM2gqiCgCvLNKL1QVcio0LYuOkw8F8jjmVGogoyKg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K3HBye8izELKNo4ORO2x2R/YBRkPV9uzAit8axHlOuzdZhaHGGHKCYRu+zZCl+r+0bhlL2ldLkzcykTA28HRwayAF+n/l9+VoXi6wdi8FJ78KiGDlAgE3+st9iAugDg7R9qLaF+x1Te09WnSrxW3GP/hataX3y3oLyIgg/4ANiE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 C420A1E8D; Sun, 4 May 2025 16:32:12 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D3CC3F58B; Sun, 4 May 2025 16:32:21 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 6/7] arm64: Kconfig: Remove GCS restrictions on UPROBES Date: Sun, 4 May 2025 18:32:02 -0500 Message-ID: <20250504233203.616587-7-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" Now that the uprobe paths have been made GCS compatible drop the Kconfig restriction. Signed-off-by: Jeremy Linton --- arch/arm64/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index a182295e6f08..b962a1321ebf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2236,7 +2236,6 @@ config ARM64_GCS default y select ARCH_HAS_USER_SHADOW_STACK select ARCH_USES_HIGH_VMA_FLAGS - depends on !UPROBES help Guarded Control Stack (GCS) provides support for a separate stack with restricted access which contains only return --=20 2.49.0 From nobody Sun Feb 8 14:31:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5D05024BBFA; Sun, 4 May 2025 23:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; cv=none; b=PM6qEsYZHfCZoRUWpOBzz9vDId71SNBnj/C5RiM8gF/SL1SMfkGJKF4tAP652sKBwIWkh5wYQO3IuGZkVW/cEy+2ZC0amjUylO62vWN7itxgIqPKs/1AtieEwzvnxl9kah74mqVkZd17VkAw+t1sdVdP+E7pINEKNNKhfmWD2Lw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746401544; c=relaxed/simple; bh=iHxExqdpCUO0hZu9dF77QQEQ3XQrFK96IJ2ClCtqM3U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MZGIe2AYCyd40OKA3na/G1UKtB+DzuRMgOnBwmkEfbtUPiXoMV8czJ98tJhBYQtvoOa2ybH27yiLy/rS1zrH9nG/Zvs+2QHTsTVgWj2MAKfn0QwHqBY2MWjAshU3D0SQU+rOgwxFdME5LGnoCvZGEh8OJDV7XrI1dop/dUlKM/E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 CD9B31EA6; Sun, 4 May 2025 16:32:13 -0700 (PDT) Received: from u200865.usa.arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 80C013F58B; Sun, 4 May 2025 16:32:22 -0700 (PDT) From: Jeremy Linton To: linux-trace-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, thiago.bauermann@linaro.org, broonie@kernel.org, yury.khrustalev@arm.com, kristina.martsenko@arm.com, liaochang1@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [PATCH v3 7/7] uprobes: uprobe_warn should use passed task Date: Sun, 4 May 2025 18:32:03 -0500 Message-ID: <20250504233203.616587-8-jeremy.linton@arm.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250504233203.616587-1-jeremy.linton@arm.com> References: <20250504233203.616587-1-jeremy.linton@arm.com> 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" uprobe_warn() is passed a task structure, yet its using current. For the most part this shouldn't matter, but since a task structure is provided, lets use it. Signed-off-by: Jeremy Linton --- kernel/events/uprobes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 8d783b5882b6..6552d9815292 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -120,7 +120,7 @@ struct xol_area { =20 static void uprobe_warn(struct task_struct *t, const char *msg) { - pr_warn("uprobe: %s:%d failed to %s\n", current->comm, current->pid, msg); + pr_warn("uprobe: %s:%d failed to %s\n", t->comm, t->pid, msg); } =20 /* --=20 2.49.0