From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-108-mta202.mxroute.com (mail-108-mta202.mxroute.com [136.175.108.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7342335F180 for ; Mon, 18 May 2026 06:52:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=136.175.108.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779087142; cv=none; b=AWGgF8DPYcidmR+UCI6ZIOEYIEdid5NnXmGnkI7jv4Q9MY1dPe4wJlIDX2kxhH8OAvrxiJ8XoO8SC+A2LLgW54XXwtd8JhW3h1lPVhj59wDNTe32nDz1yPYRy0qudTJ7P6FFKKRNaPBX/IGxqllW0vxYmvhwKFiNPh+6npVr6wo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779087142; c=relaxed/simple; bh=9Ul8tDS8RWFcTTIB7woEmHR85Y17odDIHxPntVubcGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ogOAeNGCFq3MUjxOXgfS/Ryw/VkOyAUzPiWay1JGk6UZgvO7uynjCtJTP+5mRG2NA6rxbeh/Jlm8yVHTmKMBUxu5nqkAp81xsMaxuRHce2G6P4It0XGz6+xFHBKkoMGz4i5v0p3aYiIeiZF2m5OiEs15cCpx4JiY5F5K3Wowkxw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wii.dev; spf=pass smtp.mailfrom=wii.dev; dkim=pass (2048-bit key) header.d=wii.dev header.i=@wii.dev header.b=YI4PRc4v; arc=none smtp.client-ip=136.175.108.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wii.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wii.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wii.dev header.i=@wii.dev header.b="YI4PRc4v" Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta202.mxroute.com (ZoneMTA) with ESMTPSA id 19e39d69e2400067f7.00c for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 18 May 2026 06:47:07 +0000 X-Zone-Loop: d3383a0810f8d507515e858f2c630811aba89b052297 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wii.dev; s=x; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc :To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w0UMA+XCQeCnqyZuB8gmN29dfFtWO2qyTm3HmkBTUuU=; b=YI4PRc4vDwNj+zXZNo9U/emECj YKzWO813etclhr4C/YNrEh47L/JglHJOilKiKHsbVy8AgDYzzXfcq3BJpWGDF1EAYMvhn20KDeaOh 4UqL3gRmEPrvHv9vK7yPvroLm0pBgOVJxahE0AlgNaMv+16Mk4OxW4pJPzhj+z/EpMYTrwc47jJLo ujsRsSW/TgnzMwrYEeaPqQiHe95nUdpMUOakxKQXh6CBXCHDI240Okr0vqfTG3+IQ4JqS2aWSB3PE MCjXvvvHpfNVvS6B8c71ppn2Ym6jWch1M/yyjixNuBuroX1/uMSExPYC1YOWtjImsJI3ialQ/NyiO J4MLY5/Q==; Date: Mon, 18 May 2026 06:46:56 +0000 From: Richard Patel To: x86@kernel.org Cc: Rick Edgecombe , Yu-cheng Yu , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andy Lutomirski , Kees Cook , Peter Zijlstra , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/7] x86: expose user IBT via PR_CFI_BRANCH_LANDING_PADS Message-ID: References: <20260517183024.16292-1-ripatel@wii.dev> <20260517183024.16292-6-ripatel@wii.dev> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260517183024.16292-6-ripatel@wii.dev> X-Authenticated-Id: ripatel@wii.dev Thinking out loud ... sorry for the noise On Sun, May 17, 2026 at 01:30:22PM -0500, Richard Patel wrote: > +int arch_prctl_set_branch_landing_pad_state(struct task_struct *t, unsigned long state) > +{ > + if (!cpu_feature_enabled(X86_FEATURE_USER_IBT) || in_ia32_syscall()) > + return -EINVAL; > + > + if (t != current) > + return -EINVAL; > + > + if (user_ibt_locked(t)) > + return -EINVAL; > + > + if (!(state & (PR_CFI_ENABLE | PR_CFI_DISABLE))) > + return -EINVAL; > + > + if (state & PR_CFI_ENABLE && state & PR_CFI_DISABLE) > + return -EINVAL; I noticed the caller doesn't filter input arguments, so uapi could pass garbage flags, and we need to filter here. Will fix and add a selftest for this in v2. I think the RISC-V code from which I ported this has the same problem. > +void reset_thread_ibt(void) > +{ > + current->thread.ibt = false; > + current->thread.ibt_locked = false; > +} Should I add a comment here explaining why setting U_CET MSR is not necessary here? > reset_thread_features(); > + reset_thread_ibt(); There is quite obvious overlap with ARCH_SHSTK here. The problem is that 'features' is gated by USER_SHADOW_STACK, and I didn't want to cause a mess there before asking. x86 maintainers, what is your preference?