Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3606800ybv; Tue, 25 Feb 2020 04:15:21 -0800 (PST) X-Google-Smtp-Source: APXvYqye8xUcXgPJDuEazb2gPrKUESEkv04hOV+btBygjiXkSuc3euFowm20nlh/juOqveeqNOsZ X-Received: by 2002:aca:1a10:: with SMTP id a16mr3340440oia.9.1582632921097; Tue, 25 Feb 2020 04:15:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582632921; cv=none; d=google.com; s=arc-20160816; b=BsGrVp4qWJI674irT809dm3pOgRu/55AdM4A2NjVA9DpZ8Dg9jAVkzMjlpfb+Gnsr/ BIxFPZsWpKpcCm2JyrLax8R3tCKXcoZ46LgLrIKZrrtHrsN9hYMGm02LQUCNpnjsfVPN 10Xk934Jexdb0Ssmc3qSwAx4TH1oSoSR3iE1suaFWHgNJmwGXmAgQ1qXsxDb0/unKIZS Zrhd/kpszg668KTR93Dfas2hYlMEp8z+fLbzHiaoHz+CgfcInOHzrmuUf2Pt1/tSop6q 6yoOLqXQvgUatnK5BeErEmvMblGHqOe10bGrty/1d/hjCF+zT+vS4wRi//MaNMRHmhT1 4D4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3RPlr0mIcETDfqKo+7c0LLatJtQQ45Xjp9zdjo8+qlQ=; b=05K7Jv+NzQCRGjdgsc/2jUjMstHrkdq3ETU5zNA6H4juZYCLZ9mc5EVa0TQ7kJP6Xx psqzlkZw8Q2Sh0AcWudw9u/QibdFSZMeaAZp3fLBYTDQaHSYFZSbTE7shotZda0tm9FZ 8c7BQd/+DjZdoPewhTzeBbgKu1R8A4eZAsVk23HWjch41EDUufBMcqQnHrIxXwOCkSIb gKrn3n4nvYH/rowBNTVjilISgVU4/1hLnvb2QT4eLwdYeliTXxmo6Bmrxib0zDV8lDGS zHS2p12zVHXjGe1KKTe48p/yM8+7jwcEzRwXq0vyj6UXYeX5YbDsJEFy8T5S2XyIWAxu ECGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si7966135otq.250.2020.02.25.04.15.07; Tue, 25 Feb 2020 04:15:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729377AbgBYMLa (ORCPT + 99 others); Tue, 25 Feb 2020 07:11:30 -0500 Received: from mx2.suse.de ([195.135.220.15]:44374 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729033AbgBYMLa (ORCPT ); Tue, 25 Feb 2020 07:11:30 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A48AFAC66; Tue, 25 Feb 2020 12:11:27 +0000 (UTC) Date: Tue, 25 Feb 2020 13:11:25 +0100 From: Petr Mladek To: Miroslav Benes Cc: Will Deacon , linux-kernel@vger.kernel.org, kernel-team@android.com, akpm@linux-foundation.org, "K . Prasad" , Thomas Gleixner , Greg Kroah-Hartman , Frederic Weisbecker , Christoph Hellwig , Quentin Perret , Alexei Starovoitov , Masami Hiramatsu , live-patching@vger.kernel.org Subject: Re: [PATCH 0/3] Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol() Message-ID: <20200225121125.psvuz6e7coa77vxe@pathway.suse.cz> References: <20200221114404.14641-1-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2020-02-25 11:05:39, Miroslav Benes wrote: > CC live-patching ML, because this could affect many of its users... > > On Fri, 21 Feb 2020, Will Deacon wrote: > > > Hi folks, > > > > Despite having just a single modular in-tree user that I could spot, > > kallsyms_lookup_name() is exported to modules and provides a mechanism > > for out-of-tree modules to access and invoke arbitrary, non-exported > > kernel symbols when kallsyms is enabled. Just to explain how this affects livepatching users. Livepatch is a module that inludes fixed copies of functions that are buggy in the running kernel. These functions often call functions or access variables that were defined static in the original source code. There are two ways how this is currently solved. Some livepatch authors use kallsyms_lookup_name() to locate the non-exported symbols in the running kernel and then use these address in the fixed code. Another possibility is to used special relocation sections, see Documentation/livepatch/module-elf-format.rst The problem with the special relocations sections is that the support to generate them is not ready yet. The main piece would klp-convert tool. Its development is pretty slow. The last version can be found at https://lkml.kernel.org/r/20190509143859.9050-1-joe.lawrence@redhat.com I am not sure if this use case is enough to keep the symbols exported. Anyway, there are currently some out-of-tree users. Best Regards, Petr