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 041BD26B973 for ; Tue, 19 May 2026 13:28:12 +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=1779197298; cv=none; b=uqRiEiToFotGf4dBKdy+2PdrkSQeejv0Z+qYVpQIqUrcR+FdOGvgQLVAIG0xHlXmC6c3rV/rxqlhZEQqamhfgEM9HZcwll2PltoDOEKtRESZt0169ksC3JEwZL1CKGUtN0PvzwciIEec6TUtjHmhIIO6y3fbwKSXBPrfX6JnMBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779197298; c=relaxed/simple; bh=iwHc29LNnLpmUOg2eutx8cbS33+wCQg+i+k0OsnCsQc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qWlB8OT0WlRQoM6LwLtB+vxqKZZXH5x22Aq+WOy4RXweN640IPKD/BNrNVwEu4520KHnaRVU9LKm9RtR8d+l9zmanFD6Tdt5chZXUpd5V96O3BNLTbyJX7zl4pCOGHo2zMn6T3GQ0bK7ZnraKYsPv1udz89EaibhwoPR2qzAwPg= 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=jY+XAXDU; 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="jY+XAXDU" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4893940bb5eso19295835e9.3 for ; Tue, 19 May 2026 06:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779197291; x=1779802091; 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=yrnAXjb4+RnoNs7vk9iNrF9lZLJCz88N2UJo020BR1s=; b=jY+XAXDUvWafwzDWL6vMFqWBJReUbuGjs761BQhVZHb8UsPXCv8uUX+hfDEHMpO6av E/j5rYNY58Xn0Lp6sQKZut/pxWnmJp4GqjHro8ZfOx2C4hWDgotMq9lez5qMK2x9bgYg 5Hr9MdqtD0Vk/mNo7JPk+vinkp+oKPk7NdD6WNL5b+H8xLRUFVqcQKAb2cZIs87oaYoK yEh0oHMGhBc4hXwsMNdiQRhMkqJW/WIIvK70N0YzqeYYkv+abB2k9Z6lIsulp9Jl64K+ seBTfAJxDVEUoJcjIUWmDs024TvPWm4tjSARTR+YUY5JqbsNrOzBrI3AH95ewpN76ewv RF4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779197291; x=1779802091; 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=yrnAXjb4+RnoNs7vk9iNrF9lZLJCz88N2UJo020BR1s=; b=SJ/Bt3Ybr49jJckBRM7w9V5lr9uu4JUEVgXjdL64xNcQrkAqtmv/bX6hP7ycG3ZtSK 950s0ar5yibaJVTmcSctUPX4Ldfv69P0KExAVPzHtKOG6csfZqLPCupHZ/aUU/WHdSuF utu3csruQ6cFEObhZUB40jKmY8DACXQIBVOZfQomtmjPGTZqwS/IzDKYZGHDFrfwoHUu BCVJ6j4hOZMvR0cr34qH9Exj15JsVCg4kLxrnAYerN+nHtBKU4673UFgz4lPdx8Vb9OP xcxDSfJ9XO778C916RYjeO933alCUo5ONORuz91Jb2bKZ5f5ZSsAGfjNs9kEmp+rnvN7 yL3A== X-Forwarded-Encrypted: i=1; AFNElJ8b3ZZVlZKto+xYZfCm/iqUkEkMuW7ZIoC1dcJDXoGqdoJcB1TXUrS9J9onN35JRYxxVVzC3GzZEv3YAfE=@vger.kernel.org X-Gm-Message-State: AOJu0YyqeK1hedqzFDju3jrUy77ZhcG7vbggWoZeh59Ed74bOCKd9hWO qHhapj0crCqnbVKPRAwDBAFg3r87zXG80C619AhiNmwJEdQ4BqeWHL9a X-Gm-Gg: Acq92OFgiHU7LtLFcUCv0TTdrhHEOYN6KHC732rpiLzkag7nJR1ziRHBcC4qDxkhmdz t9eJGVf7BJXo8yTQarMyI8MlklAcC2YmI+fDlWkLyRl41JtbxEzojqlZjPNgacdkZI+v/lbGajx tfluOGs6W4ho67OztvQoxOOcrxGqmWGFucxYQ+vaLiIv3kxZNP4h69HwFQDR+h30AOxEJlSxv+N U5h2mvHRfRQEusJ30HfUOCQr+l9oddiTUKg9PDtCaQD+MoktW3sB+XJFRcsW5s/VTo4NZ7JgPf7 R8Gljye6ELAP7+v6g77zNHIZ5THNxXpo6+9/ILE5bTC6XbyEDyIzlgxZVAe7Y9tTMihlnJDNjoe sj/3dJt68UhSNgEi/jyLliBW4hM4QbP0pGzLg5Wv94oPTM8cejl9hXr95kk3kpx+uxcWZBTuP/a VlkuvSl8yizt+jSlrrz6LKQeuRWwo9WDkYjRsAH3I9Z/xtfMUdO7NiarB7o0oAQr5+FeEKOxJkI ww= X-Received: by 2002:a05:600c:35c5:b0:48f:f64c:c314 with SMTP id 5b1f17b1804b1-48ff64cc4d1mr253393515e9.30.1779197290857; Tue, 19 May 2026 06:28:10 -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 ffacd0b85a97d-45d9e767cb9sm43969624f8f.2.2026.05.19.06.28.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 06:28:10 -0700 (PDT) Date: Tue, 19 May 2026 14:28:08 +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: <20260519142808.0d3605ab@pumpkin> In-Reply-To: References: <20260517183024.16292-1-ripatel@wii.dev> <20260519103345.49e52ceb@pumpkin> 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 Tue, 19 May 2026 13:14:33 +0000 Richard Patel wrote: > On Tue, May 19, 2026 at 10:33:45AM +0100, David Laight wrote: > > 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. > > You're right. I was worried about an invalid jump table index at first. > Clang 22 happily optimizes away jump table index bounds checks. GCC 16 > seems to be more careful. We should probably patch LLVM to never > optimize it away, e.g.: > > // funny.c > // clang -c -fcf-protection=branch -O2 -o funny.o funny.c > // objdump -d funny.o -M intel > int t0(void), t1(void), t2(void), t3(void); > int funny(unsigned long target) { > __builtin_assume(target < 4); If you use __builtin_assume() you get to clear up the mess. I don't know if userspace ever cares about speculative array access. If it does you need one of the mitigration - eg using cmp+cmov to generate a jump table index that references the 'default'. -- David > switch (target) { > case 0: return t0(); > case 1: return t1(); > case 2: return t2(); > case 3: return t3(); > } > } > > // Clang 22 > 0000000000000000 : > 0: f3 0f 1e fa endbr64 > 4: 55 push rbp > 5: 48 89 e5 mov rbp, rsp > 8: 3e ff 24 fd 00 00 00 00 notrack jmp qword ptr [rdi*8+0x0] // vulnerable > 10: 5d pop rbp > 11: e9 00 00 00 00 jmp 0x16 > 16: 5d pop rbp > 17: e9 00 00 00 00 jmp 0x1c > 1c: 5d pop rbp > 1d: e9 00 00 00 00 jmp 0x22 > 22: 5d pop rbp > 23: e9 00 00 00 00 jmp 0x28 > > -Richard