From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 A149138DD3 for ; Wed, 8 Apr 2026 11:43:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775648609; cv=none; b=QxDMZFAAFzD5sB3azMnH4bPIdMfwP5TluSMLXXkC7ImhtDCcwCshqjRhUBx5MlKYybT22UVcOAjzKwW1TUwatXrbGmazUO2hm8n9BRBInXYL2yacLEAqsoQEOFrA7V2g0vJPNDyB7dhErv02rVe2VctaipM5Bsey9Dzfag8qi+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775648609; c=relaxed/simple; bh=0Iw6mGP//V6mS3mSSxrnwZh3I5rO08ixkcyfybY2sjg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vFh4mU38snK2PLW0Uk11EA6EVUIjKqBn8G7ZDl8jduY0pHF60hyVdzQZ5KvYHc16tIN/BcJCocX76ULLHzn0wL1r/ke/bTVTEUrcCtZnU0rcJ6V44/H7/LV/fxiGYfc1/iHNYI2m0GLpcpDmhLiTyctCdP5JayRhTqClULhCPvc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=OJVdvC9X; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="OJVdvC9X" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43cfb723793so3983647f8f.2 for ; Wed, 08 Apr 2026 04:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1775648606; x=1776253406; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sSbTciqRiCcbNgR+vjo6/IWbGCPIZk8c8UuLFG9aTok=; b=OJVdvC9XuwV9x7RaxABcqspbPGHjUnYsDbdVX2O18JbcLp0txdb4rxQewq/Jxj9Dii a46y3KSCO0xVFxemJJhLXCCEUDG04Hnd4y5pI2LW12Chh9K0m2z0IzMyhfK+WE+GzLl4 3hw8XRYzmoI2s+tjpJuhW9kOXiDYgwltSBkFWGk0XNfx3j0esC8CD+BBg+IIbzfnY8E7 Y0bnnHVBUsdOVfaezuNQhhyd0+xZlVRKVMLgBTmDCkSKQ+320B25VYjNPdxM+xINHpZ6 2xI/VV4x9ybuRHmDPRZvFsvfgQgfhRX0MD/yKJZID3NFvNdPz73Jbufwd9XZcGymClaZ lE+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775648606; x=1776253406; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sSbTciqRiCcbNgR+vjo6/IWbGCPIZk8c8UuLFG9aTok=; b=b7HGgKgFLGxyLLScmwYWlhy3j8DxUYk3VIJVTGp+cOB5ZxYHwyV4MoC52Axfubuz44 1m2L2Sk8xw+momY/toSYKEnTQ4uqZK9PqpT758IL5ZFgA/O5oZpuzgb6bol7PYbmHyek AwCMcBBp5VVI3fcFXMsecToqKnULfEFz6+qWRedGSAUw76TWnes+79NrffnCrfO+OZso QAP9GonFCo7Oh79VOp0DMYVSv9FrBgNuX3h4gTvwVkSY/alde1dqkXkkRHsnyp7rsXhz oCxejjLae/dO9uf5UM8009Y/Hj6x8wRRq65teqE610MAnUmIsc2yb+YoMQNV9JvoYiqd xFew== X-Forwarded-Encrypted: i=1; AJvYcCV7xzVKVs69mNJ7Qyy13QLhL7mmucbLgqbQ0PicLYKdEg1fd5O7wOWq1e16JmF5mM6nKlI=@vger.kernel.org X-Gm-Message-State: AOJu0Ywi49nZJUn4zUu0qIziUIweyMmWh+8KI8F2uNqep89OqhE2kJDN JvlipWiMYOKVbwaPGZbFoNfRNTaO3zy0BVqjuzWJ5hBJGmBYJs/f6pkUMh3LLbZabOk= X-Gm-Gg: AeBDievmGL8/LQvqdWOp6l8FL0elY+WOo3ucDTrk2aDOAP7l8wSJtjj5fFPsbSS9RO4 854WrEBE36VOKrJoxZO32C/bda/rQKM953hQ9em8gDKa7BAD722eD82H8qZTbJDvKMiYFuiOVav wP4MztlqCJhCE4QVeHZ4hIHFHcvBDy7eTlixU8tz/9CfKWn+Qt7JJbL8yh4YztQX3H9dNfelzBn HQKraQDr2L5bhNx032VnWzoUTIETzZX+K+xeQGZDe1crB6Q56n3xOm9V5Fwri31lIIuJfnyqfj8 n9O6/KA2ZgJGQbLKBptV1FRr78rpu1pRm31FSKPugBE8tawubg+XK+Oef+E64UX5LUFBoA2vshP pVFJzLz2DX3sy9QMI8aGRpTcnmdVMOgyZPc31Iyz56i0q4duLIYQkAx9Nw08UjBh7KdkeplVjxY 7W5/BFM098oTvdZZN2COeIk3t4wg== X-Received: by 2002:a05:6000:2c0a:b0:43d:1bf6:930 with SMTP id ffacd0b85a97d-43d293060fdmr33267956f8f.47.1775648605887; Wed, 08 Apr 2026 04:43:25 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d1e4d29bbsm58799790f8f.21.2026.04.08.04.43.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 04:43:25 -0700 (PDT) Date: Wed, 8 Apr 2026 13:43:22 +0200 From: Petr Mladek To: Yafang Shao Cc: Song Liu , Joe Lawrence , Dylan Hatch , jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz, rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, kpsingh@kernel.org, mattbobrowski@google.com, jolsa@kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com, memxor@gmail.com, yonghong.song@linux.dev, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [RFC PATCH 3/4] livepatch: Add "replaceable" attribute to klp_patch Message-ID: References: Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed 2026-04-08 10:40:10, Yafang Shao wrote: > On Tue, Apr 7, 2026 at 11:08 PM Petr Mladek wrote: > > > > On Tue 2026-04-07 17:45:31, Yafang Shao wrote: > > > On Tue, Apr 7, 2026 at 11:16 AM Yafang Shao wrote: > > > > > > > > On Tue, Apr 7, 2026 at 10:54 AM Song Liu wrote: > > > > > > > > > > On Mon, Apr 6, 2026 at 2:12 PM Joe Lawrence wrote: > > > > > [...] > > > > > > > > > - The regular livepatches are cumulative, have the replace flag; and > > > > > > > > > are replaceable. > > > > > > > > > - The occasional "off-band" livepatches do not have the replace flag, > > > > > > > > > and are not replaceable. > > > > > > > > > > > > > > > > > > With this setup, for systems with off-band livepatches loaded, we can > > > > > > > > > still release a cumulative livepatch to replace the previous cumulative > > > > > > > > > livepatch. Is this the expected use case? > > > > > > > > > > > > > > > > That matches our expected use case. > > > > > > > > > > > > > > If we really want to serve use cases like this, I think we can introduce > > > > > > > some replace tag concept: Each livepatch will have a tag, u32 number. > > > > > > > Newly loaded livepatch will only replace existing livepatch with the > > > > > > > same tag. We can even reuse the existing "bool replace" in klp_patch, > > > > > > > and make it u32: replace=0 means no replace; replace > 0 are the > > > > > > > replace tag. > > > > > > > > > > > > > > For current users of cumulative patches, all the livepatch will have the > > > > > > > same tag, say 1. For your use case, you can assign each user a > > > > > > > unique tag. Then all these users can do atomic upgrades of their > > > > > > > own livepatches. > > > > > > > > > > > > > > We may also need to check whether two livepatches of different tags > > > > > > > touch the same kernel function. When that happens, the later > > > > > > > livepatch should fail to load. > > > > I still think how to make the hybrid mode more secure: > > > > + The isolated sets of livepatched functions look like a good rule. > > + What about isolating the shadow variables/states as well? > > We might consider extending the klp_shadow_* API to support the new > livepatch tag. It would be nice to associate shadow variables with states so that we could check which shadow variables are used by each livepatch. It is partially implemented in my earlier RFC, see https://lore.kernel.org/all/20250115082431.5550-3-pmladek@suse.com/ > > > > That sounds like a viable solution. I'll look into it and see how we > > > > can implement it. > > > > > > Does the following change look good to you ? > > > > > > Subject: [PATCH] livepatch: Support scoped atomic replace using replace tags > > > > > > Extend the replace attribute from a boolean to a u32 to act as a replace > > > tag. This introduces the following semantics: > > > > > > replace = 0: Atomic replace is disabled. However, this patch remains > > > eligible to be superseded by others. > > > replace > 0: Enables tagged replace (default is 1). A newly loaded > > > livepatch will only replace existing patches that share the > > > same tag. > > > > > > To maintain backward compatibility, a patch with replace == 0 does not > > > trigger an outgoing atomic replace, but remains eligible to be superseded > > > by any incoming patch with a valid replace tag. > > > > > > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h > > > index ba9e3988c07c..417c67a17b99 100644 > > > --- a/include/linux/livepatch.h > > > +++ b/include/linux/livepatch.h > > > @@ -123,7 +123,11 @@ struct klp_state { > > > * @mod: reference to the live patch module > > > * @objs: object entries for kernel objects to be patched > > > * @states: system states that can get modified > > > - * @replace: replace all actively used patches > > > + * @replace: replace tag: > > > + * = 0: Atomic replace is disabled; however, this patch remains > > > + * eligible to be superseded by others. > > > > This is weird semantic. Which livepatch tag would be allowed to > > supersede it, please? > > > > Do we still need this category? > > It can be superseded by any livepatch that has a non-zero tag set. And this exactly the weird thing. A patch with the .replace flag set is supposed to obsolete all already installed livepatches. It means that it should provide all existing fixes and features. Now, we want to introduce a replace flag/set which would allow to replace/obsolete only the livepatch with the same tag/set number. And we want to prevent conflicts by making sure that livepatches with different tag/set number will never livepatch the same function. Obviously, livepatches with different tag/set number could not obsolete the same no-replace livepatch. They would need to livepatch the same functions touched by the no-replace livepatch and would conflict. So, I suggest to remove the no-replace mode completely. It should not be needed. A livepatch which should be installed in parallel will simply use another unique tag/set number. > This ensures backward compatibility: while a non-atomic-replace > livepatch can be superseded by an atomic-replace one, the reverse is > not permitted—an atomic-replace livepatch cannot be superseded by a > non-atomic one. IMHO, the backward compatibility would just create complexity and mess in this case. > > > + * > 0: Atomic replace is enabled. Only existing patches with a > > > + * matching replace tag will be superseded. > > > * @list: list node for global list of actively used patches > > > * @kobj: kobject for sysfs resources > > > * @obj_list: dynamic list of the object entries > > > @@ -137,7 +141,7 @@ struct klp_patch { > > > struct module *mod; > > > struct klp_object *objs; > > > struct klp_state *states; > > > - bool replace; > > > + unsigned int replace; > > > > This already breaks the backward compatibility > > It doesn't break backward compatibility. It does. Livepatches with .replace flag set would need to define: struct livepatch patch = { .replace = , } instead of struct livepatch patch = { .replace = true, } Best Regards, Petr