Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6367398rwr; Tue, 9 May 2023 14:15:05 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7ndpQ+wgZWCV6FpXQL0SU7ZyvefBzYIPiR/wUmmgoT3L0JED7QiXRX87X57PX+4OpdgSnm X-Received: by 2002:a17:902:ea07:b0:1ac:b0c5:77e5 with SMTP id s7-20020a170902ea0700b001acb0c577e5mr350375plg.68.1683666904769; Tue, 09 May 2023 14:15:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683666904; cv=none; d=google.com; s=arc-20160816; b=l6J/M17aLG/sV7QQuZjrzqodFvMhRh02/Oygy+uR+XE2ApYO1T5U8nnv1VYiPNaXWR OzLj7qbJOWJgsf6gxbw+85wyi1AwGgF0TZ+3CtW6RPV4GMeWBg8eweK0lNzIpwtVkXxR GqUdmxRfmSMrWzU4ngEdFeXDv5Qhk/7XCFxwYsRAcv9aP4WOLDzW/ubs/d+WPNGdpX9B XyueQUdU8FjIz1TA3ug7p8yqE/sjIy+CiyxpBOGQx1+12Ga5/ed6Xae4vl/7OW/WZXJQ eV7IgoBhE0VmsEHwuk1hOiT/+LRqAd9ghUTnt1ojtS5U5Bffi/V67Z2VIxNLbtkLJlws ARhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=K3D8zA2tmAmIa323+7ZF/XLPZJO7JogZ7ToR1HtZFDM=; b=ElcG0zaQCpX1+vRd4W8bnqbMzTLhNYfi8glm0QX81XR6+K6UA4Qws+5chRgjdbOLbC PEno3qwIgnOXNI9pAeRkuvb+dyLqgPDjeiHSy8qj48ZmHyqe7/uumIdRqaQUUUhQYOiT 8UdDgncS88Jqp11eVsqeRWtF80TGwo3BNMsMhrMRh28/DUZ5Fto3DP273rpDSq6OWsUw Ba6xIcb1A/9DsFpbEa0SJXQIv6qHlVp9YxsBCsAPmU7aUzl2HXCeAhm3zLunpQPC/nDS VeGZLnFcH71CAQZQs8aZxEFnguPhKl8UCB75xf3Bmu+8UA+aMQ7xbjmIcpt1JBzIlFq6 ccDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=0I8DhwtC; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=xmiFJQDx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l13-20020a170902f68d00b001ab18790b12si2654380plg.97.2023.05.09.14.14.49; Tue, 09 May 2023 14:15:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=0I8DhwtC; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=xmiFJQDx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233852AbjEIUe4 (ORCPT + 99 others); Tue, 9 May 2023 16:34:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbjEIUey (ORCPT ); Tue, 9 May 2023 16:34:54 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1239E10FE; Tue, 9 May 2023 13:34:52 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5E63D1F749; Tue, 9 May 2023 20:34:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1683664491; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K3D8zA2tmAmIa323+7ZF/XLPZJO7JogZ7ToR1HtZFDM=; b=0I8DhwtC7cuSTVHblvvoG/OReiK2L4AFZRelRMvJ2uoQMIB6Y6qLnvBiA1jityK88b9W7/ h7xhozNFf4FOIfajQRz+QVXKWApqTdPwVPfg9A/5nxCu3yZuT9rU6qWMwOu7Tfz/qn+T56 4dC1H/0CFpmohCdjxv2KWKGuzuB2eZk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1683664491; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K3D8zA2tmAmIa323+7ZF/XLPZJO7JogZ7ToR1HtZFDM=; b=xmiFJQDxWV48mWyA1idnEfNYHFeEYTbFAwbSkQBSpdzajM01VvE6m4M5IVdWqdg3Ovmy/0 5vbHjx/sDNnVmlBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D55E5139B3; Tue, 9 May 2023 20:34:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Ai+bJmquWmQjRgAAMHmgww (envelope-from ); Tue, 09 May 2023 20:34:50 +0000 Date: Tue, 9 May 2023 17:34:48 -0300 From: Marcos Paulo de Souza To: Joe Lawrence Cc: Nicolai Stange , Josh Poimboeuf , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, Miroslav Benes , Petr Mladek , Marcos Paulo de Souza , Lukas Hruska Subject: Re: [PATCH v7 00/10] livepatch: klp-convert tool Message-ID: References: <20230306140824.3858543-1-joe.lawrence@redhat.com> <20230314202356.kal22jracaw5442y@daedalus> <20230317232010.7uq6tt4ty35eo5hm@treble> <873556ag24.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 03, 2023 at 03:54:47PM -0400, Joe Lawrence wrote: > On 4/11/23 06:06, Nicolai Stange wrote: > > Josh Poimboeuf writes: > > > >> On Fri, Mar 17, 2023 at 04:29:48PM -0400, Joe Lawrence wrote: > >>> Have you tried retrofitting klp-convert into any real-world livepatch? > >>> I'm curious as to your observations on the overall experience, or > >>> thoughts on the sympos annotation style noted above. > >> > >> On a related note, the patch creation process (of which klp-convert > >> would be part of) needs to be documented. > >> > >> If I remember correctly, the proper safe usage of klp-convert requires a > >> kernel built with -flive-patching, plus some scripting and/or manual > >> processes. > > > > Not always, I think: -flive-patching or IPA optimizations in general > > aren't a concern in the context of data symbols. From a quick glance, it > > seems like the selftests introduced as part of this patchset are > > all restricted to this usecase. > > > > IIRC there is nothing currently stopping klp-convert from converting > function symbol relocations. That may be dangerous when taking > optimizations like sibling functions (and their sharing of stack) into > consideration. This is about the point I stopped to turn and see what > the real use cases may be. > > >> If nobody knows how to safely use it then there wouldn't be much value > >> in merging it. > > > > I tend to agree, but would put it a bit differently: the current > > implementation of klp-convert features quite some convenience logic, > > which, until the question of a documented livepatch preparation process > > has been settled, is not known yet to ever be of any use. > > > > Good observation and perhaps something that Marcos could elaborate on > (pros and cons of klp-convert in his experiments). > In my tests, I took the exact code generated by klp-ccp, and adapted it to not rely on kallsyms anymore, removing the symbol lookups. For data symbols, I changed it to be a extern variable instead of a pointer to it. For the function symbols, also removed the pointer lookup, and left only the function prototype, and it worked as expected. I was quite surprised that it worked quite well. But I agree with Nicolai that the tool itself could be shrunk into a smaller version. In our usage, klp-ccp knows all unexported functions and to which modules they belong, as it's currently used for the symbol lookup. I believe that kpatch-build also has similar information so all the symbols.klp and other Kbuild machinery could be avoided, making the tool responsible to only generate the klp relocations based on the undefined symbols, just as proposed by Nicolai.