From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3754C394EBD for ; Wed, 17 Jun 2026 07:08:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781680100; cv=none; b=S9FcdZeZAsrYUPQN13Vr4tY6PgRytGxpqCF1bGv5cHa8f8EwwhIF05UgMykxzHES+HspvIj+43z2E0FpfVicQyexIiu01z0YFdzIiOkjTuanlaRF9zFQyJTq8fu7NT+VSRoC9aCVZmGx5fe+2VgS0ZYyvZTgtMItB5wZoMoaJgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781680100; c=relaxed/simple; bh=ppBV1ztlESHzV/dKUqXpzuty64bEeMrmr4BCx9p8Z9U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Cc06qRiw22mGRen+4uxL8HSKdNygnoq28JF5PaLvkTU2Y0hSrcQnHHRWKSuR+Vtee9QScv+RH+HSNc85/2tcPkDGvhsiIMaDRyjQtZ4VgSmgtf29vhuLTB+GjhbyMH/yvBBr1+MkyhmT5LIa5gCdbjTvBZBZHFEDubOM6IJ/6P4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=d2HXq177; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="d2HXq177" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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; bh=SrqMVoiUFV3YlE5YU+F5yDcfWMqzhtfTz77RBBO9R0s=; b=d2HXq1770xIhY1+BsqLG2O7t8S Y1LmxEoHmsTy5yCwPD15TVbNp/rezMvZE4tEWXubVUaq9NY/PXUcnbcFC+7gDipoWBqi2JwwjiMD+ 0oDVxo2XkVyamFiyViOfaq9TXdRvm+Okjzz74UgVuE5gJV+v2/WKQvVtrvZc0/mSlk/iOQTW6bfPO O5VhrjmU3holkcdG66V8425D3sguErdPRvFiOjxi/CxCrSF6eh9THYZ0umL5XYFpqWY6c22EY/uKN GP4ZSdrw7EjM5jdsrxW4K64K3Y0Abqiam2xT6Rst9ertM2GypHjnYN0xBRsRPWa9AYpi26xFKziUZ IK2pxprQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZkNi-0000000CBQh-0eIa; Wed, 17 Jun 2026 07:08:14 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7C27C30036F; Wed, 17 Jun 2026 09:08:13 +0200 (CEST) Date: Wed, 17 Jun 2026 09:08:13 +0200 From: Peter Zijlstra To: David Laight Cc: x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zystor.com, samitolvanen@google.com, kees@kernel.org, nathan@kernel.org, scott.d.constable@intel.com Subject: Re: [PATCH] x86/kcfi: Optimize call sequence Message-ID: <20260617070813.GI49951@noisy.programming.kicks-ass.net> References: <20260612071506.GQ187714@noisy.programming.kicks-ass.net> <20260616214722.7742e394@pumpkin> 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: <20260616214722.7742e394@pumpkin> On Tue, Jun 16, 2026 at 09:47:22PM +0100, David Laight wrote: > > --- a/arch/x86/kernel/alternative.c > > +++ b/arch/x86/kernel/alternative.c > > @@ -1356,6 +1356,10 @@ early_param("cfi", cfi_parse_cmdline); > > * "Make conditional jumps most often not taken: The efficiency and throughput > > * for not-taken branches is better than for taken branches on most > > * processors. Therefore, it is good to place the most frequent branch first" > > + * > > + * NOTE: Update the kCFI caller sequence to make use of this observation. > > + * Replace the "je 1f; ud2" sequence with "jne +1; test $0xd6, %al". This > > + * clobbers flags, but those are clobbered by the hash test anyway. > > I think it would be better to give the byte sequences for both pairs of > instructions - it takes a bit of sleuthing to check they are the same size. You mean, expand the comment like a few lines above, where we have the kCFI/FineIBT contrast? Sure, I suppose I can make this comment longer still. > I think it would also be better it the code doing the patching checked > what it was overwriting. Ye of little faith :-) > Also, what actually generates the list of cfi locations in the first place? > If it is objtool, then maybe it could do the rewrite instead. The list with UD2 locations is compiler generated. Also, objtool typically avoids actually modifying code and generally prefers to just ship additional sections such that the kernel can modify itself. There is an exception to this, but there was definite grumbling about that.