From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 6B7903F074F for ; Tue, 19 May 2026 09:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779183230; cv=none; b=bU+PcVAwuoXysm4BK1xhGJxPCQdWIx3oZHg1II4pzszEQujUS+yIJpPHsoDkHSEbkDq5df44wyL9vBmP7U3gvEjNPdgwdOfDPVH1Ewe8mNdYn6Zgb3snYMECTfZ7l2ew51Rp0pf6kJe9/A+bUCUPAgL4M9pYjK0aCd5zyvP76j4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779183230; c=relaxed/simple; bh=MZ64336EcOvTT9LLzwO4iommfKZLchNDwIRgvURGiNs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IniZadgkx4ukAcsjDh6JkZKneekKrQR5j7wZEMI1d4HKePPAOAScYsdGroJqUnVZY1SRiU12LV6AVaz+JhcK2vgn6kt8LTE6juPM1W+pdlJ/LvJhvDh4yeu7Ct3fkZB3Ko1vgPUwVpMQa+zpYqxdTpm7Z5s2VCpmerxHzYJ0980= 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=CPu+SmRa; arc=none smtp.client-ip=209.85.128.46 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="CPu+SmRa" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4891c00e7aeso23908435e9.2 for ; Tue, 19 May 2026 02:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779183228; x=1779788028; 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=Wk4oMDiAJiBC2lkNmxliIsTP18c/i7C6NCjort+Ra0E=; b=CPu+SmRaajJu3NaZ4Utl9DPnxqYwW+1VfqvU4eTCla9LzEbjN0J+y0VKvYy+1Hf/21 9UXaWs8Cmytz9pmAEcjzqNHshgM2DJAzt5yzJHBJuOkA+uV/3wVVoQ5g8eU15rb2bLk1 NADK/PH6bfTmmSTzO8evni5A9dzV2UColCxD+FbvzFgoM0R4c9Cm1PUy+yt+hk2jxQTe itexd5IOU6I7E6cI/516edTOPTArpu1ELyl/zqIcrKGxL28GtkCNxJxQt5PkUac82jYI AkTXgteGRHgb5bpOexNDQrrQ1084Jyqn/3Atk9OHtbPM9aAzcwa8xQDXd7E3PLEw5Og3 w57Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779183228; x=1779788028; 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=Wk4oMDiAJiBC2lkNmxliIsTP18c/i7C6NCjort+Ra0E=; b=S5Vw7YHmNJAB3Y6GtBywRk1UXFDiHC8FvFJLR+WbmOsFxMkMPkR6RzRkpKm2Lw4Ev9 oJUjVWdv/L/OMIwamndCdUdWguoa37WAJ/mGCq9GNM5WRwSVixe79fQym+/1mRzeVu6J o7E08kpml6M6ZzhQPpaFEyZpNCfNJfQuhE4kfm0eV//flEsWZnu/EH1IhBL0aN3Q+pZx NJ77efpDLscTTM66RPnru/IcCIZc8G72+zhWRz/Q4S9fM6CotlnHt0ctybkVWpTcRhsW D7Q8cwudUde7qJDjnKLqGzJpW5nqYI0+GLG9FeI1vFNGiSDExUTyNSoGldu+bp+77gaL nMwA== X-Forwarded-Encrypted: i=1; AFNElJ/n/TjhdnkUi2njAMUNTofhvwYVUj8ahVYYhBOkyfQPvn8WBzu6y2l2vo7LuQw40yI1G+CPp5iJIgLLJRY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2xShfvOq3NiCbgv8BuujI3JMnczhbNjC4kkaajplfLUTd0yGj fpSHWfpBgz/eSYjD5FELsiIFKqdDg42QiALlFTInVErN+hJKrWzex2E9 X-Gm-Gg: Acq92OG12bfnrqeCcP3Zg0SFTJmzyX32z81t0yNqklLL4thSo94F1aVBd44G0BaQLoO 31WngyZulxIKzhQLXADDDc2dWPB9VJGx1XHgVse8vhTuxBfnYi/hWHPTtK8bZBWa3MJxIWjD2Io yeily4k1X8lPyM6Cdq632soeVymgbiC2vAcRyf2RTefzKvyrN6FVncVghMaTyeYSbW6PkioQqnw 651MdWMsbSzJVe7bunYHUE/QfvEnpr9mt3pEKxNMa5FHXDUVhvxQX2gXfqm4DReHKqc9EZ/MD0p ja9ZfSDYWS9ZihE1/PYk43F34nAPAaqYdxkMnxjAH0nKwXCZmHZezsja0wrhCXTJr4ju1AYbqO5 /KuGOOOaacrYR9Vl+YDzHCHAfqjyHIL67rLq5PfCSHjRkqNSlbMtjHO5Ha8u1YgQMcXWRri2vhe Ouj9xc8Qs9RYYPRO6D4royqF+/lZed1O+5G6r8qp7/ndwgR8icOFg+C/nofN6lpBGw X-Received: by 2002:a05:600c:5247:b0:48f:d1b8:9aa0 with SMTP id 5b1f17b1804b1-49007bdff16mr143726635e9.7.1779183227717; Tue, 19 May 2026 02:33:47 -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-48feaa2c96csm104842005e9.2.2026.05.19.02.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 02:33:47 -0700 (PDT) Date: Tue, 19 May 2026 10:33:45 +0100 From: David Laight To: Richard Patel Cc: x86@kernel.org, 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 0/7] Usermode Indirect Branch Tracking Message-ID: <20260519103345.49e52ceb@pumpkin> In-Reply-To: <20260517183024.16292-1-ripatel@wii.dev> References: <20260517183024.16292-1-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=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 17 May 2026 13:30:17 -0500 Richard Patel wrote: > I was quite surprised that the Linux kernel still does not allow > userspace to enable x86 IBT (indirect jmp/call integrity). > > Compilers and linkers have been emitting 'endbr64' IBT markers and ELF > support notes for a while now. > > The hard work was done years ago by Intel: > https://lore.kernel.org/all/20210830182221.3535-1-yu-cheng.yu@intel.com/ > > In summary, usermode IBT requires 3 things: > 1. Set the CET_ENDBR_EN bit in MSR_IA32_U_CET for each IBT-enabled thread > (PATCH 2,5) > 2. Back up the WAIT_FOR_ENDBR bit across signal handling (PATCH 3,4) > 3. Provide a way for usermode to enable it (PATCH 5) > > This builds on top of Yu Cheng's work, with some adaptations: > - FRED support > - Implemented the existing prctl(PR_CFI_*) API > - Removed ELF parsing (can be added later) > > Unresolved questions: > - Is there a cleaner way to do the WAIT_FOR_ENDBR XSAVE fallback? > - What to do about 'notrack jmp *rax'? > I leave CET_NO_TRACK_EN enabled, which weakens IBT, by enabling a jump > prefix that skips the ENDBR check. GCC emits it for jump tables > (-mcet-switch). We could introduce a PR_CFI_IBT_STRICT bit. Isn't using 'notrack jmp *reg' for jump tables actually more secure? If an attacker can write code it doesn't matter. The jump table in is RO memory so can't be written. But if there are ENDBR on all the jump table targets they become possibly useful code addresses to arrange to write into some RW function pointer table - which might be useful. -- David > - There's some obvious overlap with arch_prctl(ARCH_SHSTK_*). > Happy to use that API instead. ...