From nobody Mon Oct 6 17:04:35 2025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B456225416; Sat, 19 Jul 2025 04:38:02 +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=1752899883; cv=none; b=ItRPXdziN7brf5WN7N393bFG9UtQvkJPi3IOgiHEgwI+b2+BRkRrQFrADnxfRICEDln4hQpslwTYolM2/dmqMvGiznZEdrDVBv1vs2QuVSyvpNFOGipahvLOZbjoLq8wtj8/Zi4d3ajBcSXtCF6vvpmq3F8xhLIqH3WRrK/ulaw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752899883; c=relaxed/simple; bh=VTYNHl3TYRpGap5CUq4f/rggtDb+4sh9tqphO6FsH1Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d1gpF5yOenPLLrNbsL7DluqMkQBwonaWPJfGOo0UWRZdqjtQFrd0KEAPRqIREMc8qL+k51Y6WDkkAaydujaWYdRqdyEfF9X3Atri2zRqV7KbHFQOg1rXjNJ/AF8ZcWG0eDEKyRLpwF/rwIivYTqaqOi25vVAbW1WxgnsdEUFpoU= 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 CBB9D244B; Fri, 18 Jul 2025 21:37:54 -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 AA7463F66E; Fri, 18 Jul 2025 21:38:00 -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 v4 6/8] arm64: uprobes: Add GCS support to uretprobes Date: Fri, 18 Jul 2025 23:37:38 -0500 Message-ID: <20250719043740.4548-7-jeremy.linton@arm.com> X-Mailer: git-send-email 2.50.0 In-Reply-To: <20250719043740.4548-1-jeremy.linton@arm.com> References: <20250719043740.4548-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 Reviewed-by: Catalin Marinas --- arch/arm64/kernel/probes/uprobes.c | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/arch/arm64/kernel/probes/uprobes.c b/arch/arm64/kernel/probes/= uprobes.c index cb3d05af36e3..b7b0c25eff50 100644 --- a/arch/arm64/kernel/probes/uprobes.c +++ b/arch/arm64/kernel/probes/uprobes.c @@ -6,6 +6,7 @@ #include #include #include +#include =20 #include "decode-insn.h" =20 @@ -159,11 +160,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.50.1