From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 78E9F49620 for ; Tue, 7 Jul 2026 18:45:51 +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=1783449953; cv=none; b=JhRPg6MjvStqfEbvRdoYMyBPEdHHRFJMLkuPDBJzxejnEPPy5VDVT8iOlZTVFAvjp1mcCMAv2y7m86OVTVLy0MT6xiOtzmjkGdRsOpDY86sCs8nX0J/W/T24RRG8uWQ5HL4PxAWRoPNb7grIHqJWED75+N4qgGShQx7WQuohTr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783449953; c=relaxed/simple; bh=Hdr9NH/4oJNiK8/W1k6sdAa/nkVPu+i395aLBPkzNW8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kIWp8VZdGFqDyi3OlUsxMiyEb6lfw9NGXpyNVQ62YDRbAwHRza6oSAjUjRnlXB5Xv6qBgBCB+dAhTESymeIRNAK51XUUHi8E27mzjQgky/C6pEAF6lyf8ixzF9GQzHbleoSv9rB3BV7EtDVA7//IkIMNV7COtUS64LAW3/JAStU= 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; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=D9VUzvvv; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="D9VUzvvv" 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 56D1D2E9D; Tue, 7 Jul 2026 11:45:46 -0700 (PDT) Received: from fedora (LJ9QCPV96V.austin.arm.com [10.118.109.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5CA823F7B4; Tue, 7 Jul 2026 11:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783449950; bh=Hdr9NH/4oJNiK8/W1k6sdAa/nkVPu+i395aLBPkzNW8=; h=From:To:Cc:Subject:Date:From; b=D9VUzvvv47V3BfobtamsEuediac8cmwy1lsIAh1sZerxWafbkj6Lzrt2l2EoyPLQD dDbJG/z17xGACvGWz6oCH+t74K/R4JNjk2LS+lsPVleYtEneVU99oPkelC0NdylZFJ IybqlgYkMg0sEzvxWYv6lNOgGuwu82i916gwcY+o= From: Bill Roberts To: rick.p.edgecombe@intel.com, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Cc: Bill Roberts , linux-kernel@vger.kernel.org Subject: [PATCH v2] x86/shstk: shadow stack enabling write return code change Date: Tue, 7 Jul 2026 13:45:42 -0500 Message-ID: <20260707184542.1721085-1-bill.roberts@arm.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The WRSS instruction (the special instruction that writes to shadow stacks) cannot be used in userspace unless IA32_U_CET.SH_STK_EN=1 (user shadow stack is enabled). So the kernel *should* return -EINVAL to userspace if it tries to enable it when shadow stack is disabled. However, currently, it will return -EPERM. But, that error code doesn't fit the condition as the failure is due to an invalid state change request not a permission issue. Investigating userspace call sites, like glibc and criu (checkpoint code), they do not rely on this specific error message, nor could a userspace effectively utilize this specific return error code to indicate a difference in "I cannot enable write because of invalid permissions" versus "I cannot enable write because the shadow stack is disabled". Signed-off-by: Bill Roberts --- arch/x86/kernel/shstk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c index 0ca64900192f..eb690ba90180 100644 --- a/arch/x86/kernel/shstk.c +++ b/arch/x86/kernel/shstk.c @@ -490,7 +490,7 @@ static int wrss_control(bool enable) * when disabling. */ if (!features_enabled(ARCH_SHSTK_SHSTK)) - return -EPERM; + return -EINVAL; /* Already enabled/disabled? */ if (features_enabled(ARCH_SHSTK_WRSS) == enable) -- 2.54.0