From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 70E5337C928 for ; Mon, 25 May 2026 11:05:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779707144; cv=none; b=r1o+SlUhZRoF4wraXvE+GPmHr8LBcXdIAJdlZZsPre1XPlABOl5wL1o7++SdEdzFLRBYVaGAmei/0YtHjaKi2XZ5yvpf0HNWZbLvQRDirufKb64hsaqI8/xHBeGTfERytIxV9Jl1/ict+5jgOT+MumZG4ZFY8tBFclCcJ1gq3z0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779707144; c=relaxed/simple; bh=SZ+zUNudkrt096Gdz0iDF1lErT6brB3WPLiFOP//PhM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=K1S9FiSrIUVFwIOPIjzhCZXlG++bbe2AUSmsUXpNxFGfJ51zBWh9vRY77mhwMaTkCOxz9jHI9e2BnC2mAb1IWio572D2uuwBVjyTWypLT0upjAKWAl/rLIUvE9ks1yxd5jM7KzYvVjlP61uFcWzSdcQilKQbRmzkk/n2DNYvfaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dyhRt6ah; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dyhRt6ah" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-48d146705b4so99972025e9.3 for ; Mon, 25 May 2026 04:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779707141; x=1780311941; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=N0xl3Y4FrPDJv34h/nBHUjimDrSoScpcNKErJrkWDkA=; b=dyhRt6ahx5PaNUVYvE8dhdacq7OIitg2aQaWl/baTAIU27SXzomRELHtsY1lIqLBTY blFrNQyHcUSMZAGBRttp4Xu3oC/ly+B7V7/LGvXLTk9CusGiBw/DhJdp6w96bkIrPFt6 OS8wPnJEX4l0vaNEcANZYGciNO2RYbCSSmja89NgxFW3f10wfovSvBaRV8dPJzpxU8Bz nf3Y04Wr++qyjC/5dG2qmTGdRTns+fWMXAyODQdgvfFoNEFt9xD1nyiJgABvtCSUsDYp uZeKHifJQYCHSMO0LWrQtJngHQQco/8NzKicpaLMzBA4YjPNtVm+666yy4u51A35HTnX SJIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779707141; x=1780311941; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=N0xl3Y4FrPDJv34h/nBHUjimDrSoScpcNKErJrkWDkA=; b=g78oy+HymAIHGJiVwmTZ0q3l+RlkltV6xCuT1Krk/L8dupQqiwjcrd9kA5Yx6Z1r4a LGMaqlK2gJ6vJjM8Sf8rqCBpcfCYZImWU3d2Wp2vcdxDVrhq1JXJm97jcCZ31E4tggpR W840vMhu7BKOEQx3A+bbiG3kZyUZ8lWW3gSbu4jMe6yzajI+bETvXpVONWrTio65/AVz G6V8Yk5lTBtm5O6rsQZkkJ5WjvsLZbyefX872L+/SU4GNkEtb9z8eN6yv2uzCUwBBOF/ Hk7EqLzAOhIrU6Xo4PK8j9Tc0VC2JwVFQ015PGUIvdp/CQBm1TKpoZ3HcsmYS/RZ97HH AnzA== X-Forwarded-Encrypted: i=1; AFNElJ9rBhPl8+ksTGwtCnwTZlXS/6EnhIcr7gpXjcTJLO0P3cw3xhs1EYVs6zFE1X/jgwOndFj50FYoxwUPqZ0=@vger.kernel.org X-Gm-Message-State: AOJu0YwGuASHnRtBHiTVNDfOibqnfaEXgxrnDLQqWBmF5UVx9fK9XlSi Lo/bbJuxQiKXpyna1jpaNVcAZq2ulald2hSD1pJa4jdeTfnXJZEUUosi X-Gm-Gg: Acq92OFyB8wTqfK9+SB6m9RQrCUc43AFVibMFz2jKJ45PNDKWZVsxaZny3yoboEMLRK TRSEjXNduN+f53sqGeJ4Bpa6GDi/qZTx/ywLInylk0XIcXv7IHSJnkzjV6CfTWxqPlaI+jf1H+T PDgCnjXEGhKLtqJu4gvh3V9QNbgYTdvqi2xSJNGDLayDVjlRXx/IO9VxBvnR8DfDuWbHvafHdtD 1lMp0Mln8ZhqBXuIYf4OYfXJIt910/8ogyDrTPOeo48WErdrAcvM6B8DJOhoKwwY+tuqwfP9j1Q WMZV8INQWFZdR565jxNK/ZnRq8wGGxDCGwxxLZz7UomxD2BlB6XPb/yZtOsoTAg9UQilAshblph AEms1xj7gcczi2pltHwQQ5+2aZkiodiqqxCxDPOGftbV90vO37rXR1lU2GwggYrclEX7k/1AO38 U0CyCdfWm6q0jv+rrMmTiUnPe8XClEEU32zOUYrEumpApdCji55KyuuvI3gNOVDw4S X-Received: by 2002:a05:600c:1393:b0:490:3890:605b with SMTP id 5b1f17b1804b1-490428e0bf3mr230908635e9.31.1779707140700; Mon, 25 May 2026 04:05:40 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490454cfcaesm235940845e9.4.2026.05.25.04.05.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 04:05:40 -0700 (PDT) Date: Mon, 25 May 2026 12:05:38 +0100 From: David Laight To: Richard Patel Cc: "H. Peter Anvin" , x86@kernel.org, Rick Edgecombe , Yu-cheng Yu , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Kees Cook , Peter Zijlstra , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] x86: ban 32-bit sigreturn when user IBT enabled Message-ID: <20260525120538.1f52bee3@pumpkin> In-Reply-To: References: <20260517183024.16292-1-ripatel@wii.dev> <20260517183024.16292-5-ripatel@wii.dev> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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: quoted-printable On Sun, 24 May 2026 21:53:09 +0000 Richard Patel wrote: > On Mon, May 18, 2026 at 01:22:19PM -0700, H. Peter Anvin wrote: > > On May 17, 2026 11:30:21 AM PDT, Richard Patel wrote:= =20 > > >diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c > > >index e55cf19e68fe..7cb76d794366 100644 > > >--- a/arch/x86/kernel/signal_32.c > > >+++ b/arch/x86/kernel/signal_32.c > > >@@ -143,6 +143,11 @@ static bool ia32_restore_sigcontext(struct pt_reg= s *regs, > > > regs->ds =3D fixup_rpl(sc.ds); > > > #endif > > >=20 > > >+#ifdef CONFIG_X86_USER_IBT > > >+ if (current->thread.ibt) > > >+ return false; > > >+#endif > > >+ > > > return fpu__restore_sig(compat_ptr(sc.fpstate), 1); > > > } > > > =20 > >=20 > > Dumb question: is there any reason not to just enable it for 32 bits? I= t doesn't seem that it would be that big of a delta to Just Do It.=E2=84=A2 > >=20 > > That being said, I suspect the number of users will be very small if an= y. =20 >=20 > Hello Peter, >=20 > I researched 32-bit user IBT support a bit more. >=20 > Intel's original patches used uc_flags, which is not available in the > legacy 32-bit frame (breaks sigreturn(2)). >=20 > But you could also store Intel CET state via XSAVE into sigframe > fpstate, like for Arm64 BTI. >=20 > Unfortunately though, this includes both CET control flags ("is IBT > enabled?") and user state (WAIT_FOR_ENDBR). Since fpstate is writable, > XFEATURE_USER_CET is in XFEATURE_MASK_SUPERVISOR_ALL. >=20 > So, we have 3 options: >=20 > 1. Include CET in both XSAVE and XRSTOR, but revert user changes to > control bits before restoring. >=20 > 2. Include CET in XSAVE, exclude CET from XRSTOR. > Parse XSAVE and restore IBT state "by hand". > * Breaking XSAVE/XRSTOR symmetry seems like a bad idea? > But the user can already remove xfeatures bits, I think. >=20 > 3. No CET in XSAVE, instead abuse uc_flags to save this state bit > (this patch series). > * uc_flags does not exist in sigframe_ia32, which hasn't been touched > in 10 years >=20 > IMO: Option 1 seems crazy. Option 2 worth a sketch. Option 3 is ugly. >=20 > Really curious what you think. I'm going to send out v2 today with > option 2 (CET XSAVE, software restore), and if anyone hates it, > I will revert to option 3 (CET software backup and restore), and at > least add rt_sigreturn ia32 support. >=20 > Btw, OpenBSD doesn't do any of these and discards IBT state. > So, if you spam signals on OpenBSD, you can bypass their IBT. > That is, uh, option 4, I guess. That is still better than IBT disabled. Wouldn't you crash the program when the signal 'missed'. So there are probably easier ways to break things. I think that would have the side effect that code would run when single-stepped by gdb, but fail otherwise. If true that would confuse things. -- David >=20 > Thanks, > -Richard >=20