From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 8CDAC3815DF for ; Wed, 17 Jun 2026 11:12:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781694743; cv=none; b=A5ETqp4lVcvsxrCD4RrooopbhnjiG8v/OS84WUeK7huLVefi9qUfKZT3nN/2dhoJJTkwkYudsUvPnYfBOHebhZiPdcaXbv2jpqFKUU4DsoBYSHD2Hz3SIKljIDF7CnPWm0fMH/FCt52AHY1snxH38iDW996dNXe5t7AznwCJQOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781694743; c=relaxed/simple; bh=foqz+NCt5z6XGX/pw0HGt7duxLu9ZotxpA35DEj9X74=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HOs6I3cOOdKIFdYYI/EUs7kT0K3Sec9klea30+aGwHgSXCxU/jM3AMVwJiLAgg5i1JbrUSzY9U1z5H8/cdcHDxjLvR5JEpLaw4Tp1gYfBPhN0N3SuaG5PjEQuM7NXcAnxbntLLzXl28PYc1JZtIkBDX4gpwu8g2Ziduu4biSrvQ= 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=qoZWQZYm; arc=none smtp.client-ip=90.155.92.199 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="qoZWQZYm" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=qpc5SVTUiTObxYX4xOpr423Y9biaIEC9A1kTo+TN9bU=; b=qoZWQZYmO4q3XESsN7ZyzzSwbv MoC3O7RvWz/xu9aiSTbBbS+T7NH4Zb/BQpD4n5TrUQRgz16ZsT2d6mXxknYr1ogluNRWPRh9feIYF rENbqw6dGf0RSLivwnTd+oCtOFQSu9nR8cyj0ciUIFOwZ+gRMT2zF79qReU0DmuxKXh2jaTfjzHZg uJj7qpJZSRjrhBcZoqsDyP7wHi7ZbKO6iq5OEzBoFWdnT8TdqyJIfyGP947X3p6djc9yiOo2wV/f6 3Sxv52zybyuU+7xDalFzt+jNbUcjdGJ1YX1L2eOs80cuMKRDNPfduRkhnlmAj2QRVcBz8OEDj580/ sDPZ4uUQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wZoBk-0000000C3Dw-304X; Wed, 17 Jun 2026 11:12:08 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1DD9630036F; Wed, 17 Jun 2026 13:12:07 +0200 (CEST) Date: Wed, 17 Jun 2026 13:12:07 +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: <20260617111207.GJ49951@noisy.programming.kicks-ass.net> References: <20260612071506.GQ187714@noisy.programming.kicks-ass.net> <20260616214722.7742e394@pumpkin> <20260617070813.GI49951@noisy.programming.kicks-ass.net> <20260617102643.5b343e64@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: <20260617102643.5b343e64@pumpkin> On Wed, Jun 17, 2026 at 10:26:43AM +0100, David Laight wrote: > > > I think it would also be better it the code doing the patching checked > > > what it was overwriting. > > > > Ye of little faith :-) > > I wouldn't want to have to debug the consequences of getting it wrong. > (The same goes for patching into function preamble.) Been there, done that etc. :-) I'm the weirdo that's written all this code. > My 'little faith' comes from patching live kernel code with echo | dd :-) The thing is, objtool validates the retpolines are preceded by UD2 as marker for kCFI and complains when this is not so (there must not be unannotated indirect calls). And the code that is patching is already checking there is that mov into %r10d at the expected offset. The update poke happens when both those are true; (leading mov and trailing UD2), verifying things again has very little added value. > > > 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. > > I've never trusted compilers not to change their minds on how code > will be compiled. The whole kCFI sequence and placement is ABI, there is no changing that. It is a very specific sequence that is guaranteed to be attached to any indirect call/jmp/retpoline. > > 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. > > At least this one is an optimisation. > The advantage of getting objtool to do the change is that objdump will > then show the code that is being executed. Given the amount of self modifying code, that's a dream. Also, on anything half recent from Intel, it'll all be rewritten to FineIBT, which is wildly different from what objdump will be showing you. The only way to truly see what's running is to disassemble the live image -- either through /proc/kcore or some virtual machine gdb server.