From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.216.41 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793206015; b=nwz/vttAab9t7kDH4iNO2vsVmgAItUBg3eM+cySCVrjnEQj4g4hHiAEepNpYg3Ccn4BX 5qmo2T5Tlte56CVH6+PWjrwbf0dvtl956fpM6k5Pjg7Xv9bbysM+UEUrw9UJT5MK4hnjP 2g0FDMNczCsTdI5Pqa+fpugXTU6v/nBhFKjDbqdqWRKfXVW+97GVKNRByNgy2sqP/sri9 JW7L1S0wSjKS4OTnKLEqNXA5Spc5rJHv9T9la+LQJb3hHApr/ceS3K2aYlqSCxKa7pMxL aZ/niXmzAR5EvT6ZzFFAMaXBv56WpJed/2LFOMe4yJibkikUFzSI4lCobHdfjnaKzlw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793206015; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding; bh=g09dqGgfkECLzBz+aB2tJ6NeeH7OBTuBnp9ZDOSrA+g=; b=U/HWbLiL9u+BqUclIugMSjpN+gpd5b5HmsKY+sbLwJWn00g1njepBQ/9hPLq7Ib4Ewcu N6Xaf4zy5ibxVDL6UQDlZwHcWENpVZEgyu4wqATkeR4ZISC7fKZU/e5A4ESwM/iWlsgBl 0v6Z5JBBsZGHvLxmnYZ2VAe5gQQQgBCZHlWIbdXOKoJ2/PUe4BU0YEcyuzwgpXNb8H63d hzzTAalz/xgEaod1EMm1PQg/p9YCKYwQpgZoeh43enkYfaDuHHN08fenc7qlRABaJaoH1 HKr3rD2E+VQ67+/wBFoiEjm5SM/s92op/j9DxIpRGsNXTDHl77MeVTqy+QR2Ae8qN4g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=Kfw5lTIe; arc=none smtp.remote-ip=209.85.216.41 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9665606A31F for ; Wed, 28 Oct 2026 16:46:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org E9665606A31F 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, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=Kfw5lTIe Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-3acb11973c3so948318a91.3 for ; Wed, 28 Oct 2026 09:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793206014; x=1793810814; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=g09dqGgfkECLzBz+aB2tJ6NeeH7OBTuBnp9ZDOSrA+g=; b=Kfw5lTIeK0b+pOQ6UeoU3otNbG/F+hJLBbHJEngSvUZJX2T+MxRia790fWsYRjO+gu zctBZmF6vri7AvKN6vl25fZ88lMKL7xNhzGmKT5vzAphBDKRfVmSdyXMt2boyd+sNC+B Y1eJ5ALziL3Ty0kZRoBFzS4YX6Y4PuZhr4o2RfgzX2saVF4UCTFpQvJusL3w0/JWqHaf ih2ZAjpf2pjMmCimMqDGyF+XyRi/GjPmTkkK4NbKvltpVB3SR+/ronU3UaaWcfwCqTx+ UocDFBZjP3PAzqQgzwwW0MdCOLVUhWoTHd6LJWzNZ2Wyqulal0tkpXusZpW5jqqLYHQQ Ylcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793206014; x=1793810814; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=g09dqGgfkECLzBz+aB2tJ6NeeH7OBTuBnp9ZDOSrA+g=; b=mo5Zh2ZPHqE0tPbAsVeJBXm+IIhjFO7lgvq1Hb5j09c6u8lpmHNIRrIMy/EJpNm4Ry g6381RsyWlGzSajPYs1T7odgSVSL4oW1IOAM3GEUYg8Cu0uFiGIDwEPr99WLUjEfhz3b +F5sKKTaUR+V2nd2dJ3mcKlA46N4KepSANtWhW6ePQSyhnMiqfKyvhAwkvSY7aCPwbos ZBT/+KjQkuNjC/Ixn1N4xaNI27iG+hfrRIeaEug0r1eX+3Y1IveMPKw/MC8Yi934Nsx3 9jBpSyKGVQgMgiZlvTDYjEbLuswEJnZNfPJe5FN/+vb2K+os481plDccnXNPGkQ+lH29 XN9w== X-Forwarded-Encrypted: i=1; AKwUvBwrATCh9DVI3pr2Vchf8bXgsqLSrIn/GH3ovUh1Z24NKS6j9MhhXg7jFki1NeZ6wMHaGatiUxGp74AErZs=@vger.kernel.org X-Gm-Message-State: AFq9FYI+CC7zts25ZP/+x8i6JaVKExbJ+QomXQCeTonriuvWxuJjRSgh LCP9sKa8dKSKt/TusgNfzZ4EewLHydyJ7x6oq5jbzQsh+1is2PiwGvw7 X-Gm-Gg: AYBFou3ucrBinqQuqsiJj1d87lgGAu2iNUM9lN7pcLMJiX20beza+5t/plaPua33mDl whu0cQGrRKkjnCQjwfzRN4cNrrbokf7zZdV5TRnKrw28vLwIvdAvPv9Fzffqe2L0VvsI85BVijC YogMNPj+2ivkBAXuf8DKsRber2IPeA7XAb07eyBHnMuQ4yIbUkcl+pUO/tpGiFlK2kVVUYRahA2 FNYoJy80WR8Fy96IegJhfX2Yy9Gg6mf+Tsao0DZ7e/5NQPBmEM2Euspa3NKzOGAxy7hawb/px3P Ly8jNwElh1ca8TtvxL+C0xZVVVmw9phra+zAXCwE7eHGcNVMx0iOUEAYHcMsWk5f46i9FHp7qHu Kyn/ruwTX8GzMvKfeNnLd4rRUQ5ooGg87TiJ88CD007rSxOMd19xhV11Hf5z0gY7pl1sqabZwcK 7lkrJyIFdDNXg2qmG+gT3KUSPFwN8LMuZ6c+OMsiOk7Yf+K906AVKce6tIQOkgvDOoz1G7uIbHK NPZfgyxYnuYnE2gjC7hS8+X+wt68nagNabPvSerPx5K+OdX9vzJbrK8qy3DsQGo4w/ZtZIklaFQ yWirTulSHv0f6wSu+e09S38FRb+9+J6W7u7HKBOw9ZsHBzq9gpwQ0VKdVmX+zLuiAqb0VzlUpPM l3vMXUb7PuHRfUiodwjTr77gddwk5O4/gmF52wHvB/Bkh4P2AAA== X-Received: by 2002:a17:90b:5348:b0:3ac:8446:c1b5 with SMTP id 98e67ed59e1d1-3ae58228c0bmr2122376a91.31.1793206013689; Wed, 28 Oct 2026 09:46:53 -0700 (PDT) Received: from lima-arm64-dev.hitronhub.home (180-176-144-38.dynamic.kbronet.com.tw. [180.176.144.38]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ae5797f6aasm2083346a91.2.2026.10.28.09.46.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 09:46:53 -0700 (PDT) From: Harry Hsu To: pmladek@suse.com, jpoimboe@kernel.org, mbenes@suse.cz, joe.lawrence@redhat.com Cc: jikos@kernel.org, live-patching@vger.kernel.org, shuah@kernel.org, song@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/5] livepatch: Fail object initialization on duplicate patched function Date: Thu, 29 Oct 2026 00:46:49 +0800 Message-ID: <20261028164649.337479-1-x90613@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri 2026-10-23, Petr Mladek wrote: > I wonder how to move forward with this patchset. There seems to be > three unresolved problems: > > 1. How to handle aliased functions when replacing two livepatches > with aliased symbols, aka two NOPs on the same stack [1]. > > My take: I would fix this later on top of scoped atomic replace. > The aliased symbols should conflict. > 2. Fix the low-level __write_relocate_add() to clean its own > mess on failure. > > My take: I would fix this a follow up patch. > > 3. Better describe the purpose of klp_write_object_relocs_limited(). > Or clean its own mess a better way (code duplication)? > > My take: This requires v5. For 1, I have a proposal to create only one NOP in the first place, as in your solution 1 from the earlier mail. Recap: The problem ----------- Take two livepatches that are already loaded: A patches __do_sys_fork B patches __x64_sys_fork (same address as __do_sys_fork) and an atomic replace livepatch C that patches neither of them. klp_add_nops() finds the functions by name and sympos only, so C inherits two NOPs. Both resolve to the same address and end up on the same ops->func_stack: [A, B, nop1, nop2]. When the transition is reverted, the stack goes from nop2 to nop1 instead of back to B. Proposal -------- klp_add_nops() runs from klp_init_patch() before klp_init_object(), so the new NOPs have no address yet. But func->old_func of the old livepatches is already resolved when their object is loaded. So the address can be used as a hint when the NOPs are created: 1. Copy the already resolved address of the old function into the new NOP (func->old_func) as an address hint. 2. Do not create another NOP when a NOP with the same address already exists in the object. The hint is overwritten by klp_find_object_symbol() in klp_init_object_loaded() with the same value. It is cleared again by klp_free_object_loaded(), so it never outlives the loaded object. A sketch of the change in kernel/livepatch/core.c: +/* + * Return true when @obj already has a nop whose address hint is @addr. + * The hint is only set when the livepatched object was already loaded. + */ +static bool klp_nop_exists_at(struct klp_object *obj, void *addr) +{ + struct klp_func *func; + + if (!addr) + return false; + + klp_for_each_func(obj, func) { + if (func->nop && func->old_func == addr) + return true; + } + + return false; +} + static int klp_add_object_nops(struct klp_patch *patch, struct klp_object *old_obj) { @@ klp_for_each_func(old_obj, old_func) { func = klp_find_func(obj, old_func); if (func) continue; + /* + * Aliased symbols resolve to the same address. A single nop + * is enough. More nops on the same ops->func_stack would + * break reverting the transition. + */ + if (klp_nop_exists_at(obj, old_func->old_func)) + continue; + func = klp_alloc_func_nop(old_func, obj); if (!func) return -ENOMEM; + + /* Address hint for klp_nop_exists_at(). */ + func->old_func = old_func->old_func; } That's only one way I can come up with :D Best Regards, Harry