From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A21CC2BA1A for ; Tue, 7 Apr 2020 03:11:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D55920716 for ; Tue, 7 Apr 2020 03:11:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="jlrPkxX1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D55920716 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C28138E0094; Mon, 6 Apr 2020 23:11:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFE778E0062; Mon, 6 Apr 2020 23:11:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B14648E0094; Mon, 6 Apr 2020 23:11:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 9AA1A8E0062 for ; Mon, 6 Apr 2020 23:11:38 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 63A06281F for ; Tue, 7 Apr 2020 03:11:38 +0000 (UTC) X-FDA: 76679583876.19.oven81_e44685d54245 X-HE-Tag: oven81_e44685d54245 X-Filterd-Recvd-Size: 5915 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 03:11:37 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9CD92206B8; Tue, 7 Apr 2020 03:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586229097; bh=om8iH1fsYVMeH8nIX1RzSbuVAekeBNgUnvnecevM/4Q=; h=Date:From:To:Subject:In-Reply-To:From; b=jlrPkxX1qxLoJeDEfW83Cm5C84EY2CI8mkkWZZxpF5arKhpXzw0DyEJ4zWOAjvDCB 8Og2Wf5O2WZkpX+pIk3aSfyzScG1fbZOQ+aq20F19n9uMMokt2LiYl1ng6OgCmVK7N 5jOiyNf+nLBr7Dm+Mlg/YvThiVyKHcZeoCkEhuhg= Date: Mon, 06 Apr 2020 20:11:36 -0700 From: Andrew Morton To: akpm@linux-foundation.org, ast@kernel.org, frederic@kernel.org, gregkh@linuxfoundation.org, hch@lst.de, joe.lawrence@redhat.com, linux-mm@kvack.org, mbenes@suse.cz, mhiramat@kernel.org, mm-commits@vger.kernel.org, pmladek@suse.com, prasad@linux.vnet.ibm.com, qperret@google.com, tglx@linutronix.de, torvalds@linux-foundation.org, will@kernel.org Subject: [patch 142/166] samples/hw_breakpoint: drop HW_BREAKPOINT_R when reporting writes Message-ID: <20200407031136.19sEo9A3l%akpm@linux-foundation.org> In-Reply-To: <20200406200254.a69ebd9e08c4074e41ddebaf@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Will Deacon Subject: samples/hw_breakpoint: drop HW_BREAKPOINT_R when reporting writes Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()". 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. This patch series fixes up that one user and unexports the symbol along with kallsyms_on_each_symbol(), since that could also be abused in a similar manner. I would like to avoid out-of-tree modules being easily able to call functions that are not exported. kallsyms_lookup_name() makes this trivial to the point that there is very little incentive to rework these modules to either use upstream interfaces correctly or propose functionality which may be otherwise missing upstream. Both of these latter solutions would be pre-requisites to upstreaming these modules, and the current state of things actively discourages that approach. The background here is that we are aiming for Android devices to be able to use a generic binary kernel image closely following upstream, with any vendor extensions coming in as kernel modules. In this case, we (Google) end up maintaining the binary module ABI within the scope of a single LTS kernel. Monitoring and managing the ABI surface is not feasible if it effectively includes all data and functions via kallsyms_lookup_name(). Of course, we could just carry this patch in the Android kernel tree, but we're aiming to carry as little as possible (ideally nothing) and I think it's a sensible change in its own right. I'm surprised you object to it, in all honesty. Now, you could turn around and say "that's not upstream's problem", but it still seems highly undesirable to me to have an upstream bypass for exported symbols that isn't even used by upstream modules. It's ripe for abuse and encourages people to work outside of the upstream tree. The usual rule is that we don't export symbols without a user in the tree and that seems especially relevant in this case. Joe Lawrence said: : FWIW, kallsyms was historically used by the out-of-tree kpatch support : module to resolve external symbols as well as call set_memory_r{w,o}() : API. All of that support code has been merged upstream, so modern kpatch : modules* no longer leverage kallsyms by default. : : That said, there are still some users who still use the deprecated support : module with newer kernels, but that is not officially supported by the : project. This patch (of 3): Given the name of a kernel symbol, the 'data_breakpoint' test claims to "report any write operations on the kernel symbol". However, it creates the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas it also fires for read access. Drop HW_BREAKPOINT_R from the breakpoint attributes. Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org Signed-off-by: Will Deacon Reviewed-by: Christoph Hellwig Reviewed-by: Masami Hiramatsu Reviewed-by: Quentin Perret Cc: K.Prasad Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Frederic Weisbecker Cc: Alexei Starovoitov Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Signed-off-by: Andrew Morton --- samples/hw_breakpoint/data_breakpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/samples/hw_breakpoint/data_breakpoint.c~samples-hw_breakpoint-drop-hw_breakpoint_r-when-reporting-writes +++ a/samples/hw_breakpoint/data_breakpoint.c @@ -45,7 +45,7 @@ static int __init hw_break_module_init(v hw_breakpoint_init(&attr); attr.bp_addr = kallsyms_lookup_name(ksym_name); attr.bp_len = HW_BREAKPOINT_LEN_4; - attr.bp_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R; + attr.bp_type = HW_BREAKPOINT_W; sample_hbp = register_wide_hw_breakpoint(&attr, sample_hbp_handler, NULL); if (IS_ERR((void __force *)sample_hbp)) { _