From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 814713F8ED2 for ; Wed, 17 Jun 2026 12:36:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781699804; cv=none; b=ByDDIb0r/omG2pGpqI7BRtsNGYQV+YbQju7WNkbRNqGKj5Cuq7VX+eZ4qmq32CK8YGH4JHRMGmyhCFbGr+wXMW0H5pPrOCWg/q60mr+rGRq4eLIoL64rgDHn4Iq+uCfCthIxTcJWLpdFxq0T3HiJ89RKrLCWBjb6TSoh4WwsIlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781699804; c=relaxed/simple; bh=/Dm5XcBjAkqESA9+MrnFom6OYWCk5XOPZoT68GXB2KU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nwVyNxmiK4fWO/2U0PLbMysmbR4K9F/21a7dOKwN3I4m5Gi61gWag6YhWIOharzstxtXtzqx2Do/VFtFYTpxmYcdvWDfHFE2MZpErQwenLvtNEVelf6tSkGaao7RFtXmCJsKng0QPdenv6evXssL/dDfR44KxXzYBuMAkx0b8MY= 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=Ql3sqKWh; arc=none smtp.client-ip=209.85.167.49 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="Ql3sqKWh" Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5ad0abf1f7bso4291848e87.3 for ; Wed, 17 Jun 2026 05:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781699799; x=1782304599; 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=/TSuH8Mc/ExJUxGAA3wq4zIliMwtPGtbpZTauwXYW2g=; b=Ql3sqKWhlI3VvSwJoEGujl2vT0h0h8R/qEB1EVHcga8Ey3jX1+Uc5uIfxpL+RBpyim kqLeQSWhohxpM6Ctuj6Ls3qMkQXzCjCf5631dbaF61h7e/Wvh9D2WGsYDXV6kkRa92VP gwVF05CM7Fd+XFqEGWs1pho+Cho8a0c6KHnfq5/Yb8ZfZBy4Z++eecVtJOjGwvJ17UXx bb1RAfnR6K7iWiL5yWErIESQ8C9WK+ME2iyOOHlCqO6mM8ocs0T1/R5yPCfQEBMckVYa 2imzH7VY/D6Dxg7wOWXXImuJ1MTHlUcQKPiMRDLjQGazdu6EzfNaG0JTuwThyM37TXP3 PCPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781699799; x=1782304599; 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=/TSuH8Mc/ExJUxGAA3wq4zIliMwtPGtbpZTauwXYW2g=; b=ato4b8JB6TkfuDTqO8Y179QCDya7LxzHg8qe+hfpNSLX3Zx6KfTY4C/DtphMPurGh4 huZSoATWnB+ZdogDZFfDKUCmhMRls/sTBvJUFBMfRq80VvP26LWQY3n73CG+lCNRYXvA LGmo9jBV9zserv9dY1efk16mYcYVuclAv2NDjHu3yi0Wut4Z/n1dGjBfY/d3NfyqjVUq cRM2BmCLFvZG/NbD41JHRtr/0Z2VZw42Bm8Siv4pK2TV63jUWSku3Jyx70jwgSgw3eZT hgUTPIGTsq8frkWe0qofLOkIwNBIDsHqmOumeoN5Nh4tSEUhgFwAnWs3HTkr1UFTwAFw rJ/Q== X-Forwarded-Encrypted: i=1; AFNElJ+NH4i4niS62ALs+kXom8sIY85AzJ7t3LWs/3bUXx9l9vCX/2dXbcjt6jCG5lwjyFyUZ4Jkt9WtlSIh51U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1LS0fYx4QPnAYVKKL0bxz1w6ZwzzSVwqAheP42DmPliQQbgAy zYOnlbqz1NwrsCGOHZhBv2cO+qI+5mtwNK9h7cEQuxJsQk7pzwPHec+jiBY2TO2A X-Gm-Gg: AfdE7cn5e5p8I2GwVi5TfMX6fb2GuP+99rKUBJ5t/3uKP0L9aPpQ5Adp4uY+7Ss2gyn AwTPukLptwkS262R9mRCOAnctk1KRmUZzwVbiW5Ufo/eXzfHQenslyaCQDZ7Tjva1nfXO0/Ug/L ZPA0LGDHLCPZ/l3fzXlnIv1qvmykbD9/04z054ANRxMdkNNFYhhcIODRy8syCz1GrRRiB/JqUX9 WT+QcFCZzq3rXzpC3Pqzkt1NX04nv8VEBZOLwHdgzgZW45EsJ9mLgd+lS+K5hMDe+akNLzHDtJ1 zysG2HU3/0vgm7N5ZENn2VPhwjAHFsRM75V+SpBXE4WXIWSspcSIttzOoBDfw3QUZcxNAScjQ+B 7kjjbchniaEbJaurMYJREOQMe841a4z1fntzrKxTs1tR/oGCTkTlWdWPGygodcOM1TByeH6wb35 S5O1So/kOnePS12uOAcIEpspd7tRljUGoAy9NkPtluDL9d837Epw== X-Received: by 2002:a19:7011:0:b0:5aa:62d3:3833 with SMTP id 2adb3069b0e04-5ad46fab36fmr869194e87.5.1781699799034; Wed, 17 Jun 2026 05:36:39 -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-4606f2c3fcfsm48165623f8f.26.2026.06.17.05.36.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 05:36:38 -0700 (PDT) Date: Wed, 17 Jun 2026 13:36:37 +0100 From: David Laight To: Peter Zijlstra 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: <20260617133637.676366e6@pumpkin> In-Reply-To: <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> <20260617111207.GJ49951@noisy.programming.kicks-ass.net> 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 Wed, 17 Jun 2026 13:12:07 +0200 Peter Zijlstra wrote: > 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. And I'm one of the weirdos who knows enough asm (various) to understand what it is all doing :-) ... > 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. Ok, there is a check a bit earlier but not in this bit. I'm just wary that just believing an address in some table could easily lead to problems. ... > > > 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. I did have a local change that generated different nop*3 so I could tell what was lfence, stac, clac (etc). Trying to check the compiler output was hard when there were blocks of 6 nop. David