From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (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 C7C4643F8C3 for ; Thu, 20 Aug 2026 12:27:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787228845; cv=none; b=qjFlHmk8q0DDX07p2R8oVzHwZb23N2TuaLMUwfFfWX9QlaYFcScsRqWqUA0nvl2jyt5HGhWSggwf3NffXZXcvubmDPfauo6w9Mt9y9ds5FzoH4QtHfzxtYXdV6K6e6atss2JhcCR/vNztBcydIKGd465hWgOiDveJpODoN0cYtw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787228845; c=relaxed/simple; bh=Zj8SFmRAOHbQc5bSY0znvppvXZ8Ybd1hssGnNInHWGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NbfHdJtkViYcZWBBUAXAD6wq4D1J93HfEdRrXvO9us+ecoWOtFqT3DuuKEAQHyR7+8ZVfuXitMSSs+11tYE330farqLw0+mclilGzfCt7qm/Vr2p3GbstnA7lKjIPyCc8n6W0M7rdvTKIzjFL5xQNF6RNpxR5YeimT+yifsFQB8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=bY+3jNbd; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="bY+3jNbd" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787228832; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=2xVsDYOUg7+UocR1AiMbVhWi0R/f7vIyB3hX5jYrL2A=; b=bY+3jNbdf8coxPUCprzH3OTqANjdzW88kBLwtkPp/H20F0GVebTiOCDU0JUlyXcmLZsSsrdroIM43JgWjLgupGfV/CKRsuLDfwmFyB494vnY8z73dJlLiieroxpqbaNd/Aw22z71PxuEsKDqo64hJOzmX2UL/nkJGgmAe+tDfBc= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R791e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=cp0613@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X9JQc.V_1787228827; Received: from DESKTOP-S9E58SO.localdomain(mailfrom:cp0613@linux.alibaba.com fp:SMTPD_---0X9JQc.V_1787228827 cluster:ay36) by smtp.aliyun-inc.com; Thu, 20 Aug 2026 20:27:11 +0800 From: Chen Pei To: Guo Ren Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Oleg Nesterov , Deepak Gupta , Alexandre Ghiti , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: ptrace: reject CFI regset access when extensions are absent Date: Thu, 20 Aug 2026 20:26:59 +0800 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: <20260820063233.2567-1-cp0613@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Guo Ren, Thanks for the review. On 2026/8/20 19:45, Guo Ren wrote: > On Thu, Aug 20, 2026 at 2:32 PM Chen Pei wrote: >> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled()) > Do you want: > > /* If shadow stack is not supported or not enabled, nothing to ... */ > if (!is_user_shstk_enabled() || !is_shstk_enabled(tsk)) There are two separate points here, let me clarify both. First, on "&&" vs "||" between the two features: the combined check is intentional. Zicfilp and Zicfiss are independent extensions and the kernel treats them as such everywhere (separate hwprobe keys, separate prctls, separate riscv_nousercfi switches). Rejecting the regset as soon as either one is missing would also take away the useful part: on a system with only shadow stack, shstk_ptr is exactly what a debugger needs for shadow stack unwinding, and symmetrically for landing pads. With "&&", the regset stays available when at least one feature is present, and the missing feature's section reads as all-zero, which is accurate: its per-task enable flags can only be set when the feature is available, since the prctl paths are gated by is_user_lpad_enabled()/is_user_shstk_enabled() individually. The same applies to riscv_cfi_set(): a "||" would wrongly block legitimate shstk_ptr updates on shadow-stack-only systems. Second, on the per-task check (is_shstk_enabled(target) and friends): I would prefer not to reject the access when CFI is simply not enabled on the traced task. The all-zero state is a meaningful answer -- it tells the debugger that CFI is not enabled for this task. This matches the arm64 GCS regset, which only checks system support in gcs_get() and returns the task's (possibly zero) state unconditionally. Best regards, Pei