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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7446BCCA47D for ; Sun, 12 Jun 2022 12:31:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236656AbiFLMbG (ORCPT ); Sun, 12 Jun 2022 08:31:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231135AbiFLMbF (ORCPT ); Sun, 12 Jun 2022 08:31:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B75F84EA1B; Sun, 12 Jun 2022 05:31:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5144360EBA; Sun, 12 Jun 2022 12:31:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D957FC34115; Sun, 12 Jun 2022 12:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655037062; bh=75vg2kGshxM5YQM0eTP5ZRYR8Fcv4/li4Jk7t1TdZ38=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ihwcLZes9inwOPuBDeaJye7gcke1UBLU+1VBGf4DvKCK8cnpB6u1SzgyKO4ftcfZG ErQikmY7mpilG3tu8wVrlaHYSKH7Nu92Hyqnw97kzveTBBIVOS3uQ3Jqgu9GFW4w0/ jmS6W7bFFcvW2dOW/LuS2HXtqiKHxLtKSxRKUtWOPvP35PudVpnCQhmoWF/hc9228f gVQ4oyLRAILBu9zA0K+lA3/gxYbMJXzy+bnGsqhl3RfaVq5/VfkBb87Ki9hv8Dkl4s ONjTLXhsGE6D3ntAiXzcwMS2P7ueWXHWUvDCIewbY4eDMY//09jGQh9ejxWsMYhY9O DS4tlNoS30DUQ== Date: Sun, 12 Jun 2022 21:30:41 +0900 From: Masami Hiramatsu (Google) To: Song Liu Cc: Ard Biesheuvel , Jarkko Sakkinen , Linux Kernel Mailing List , Nathaniel McCallum , Jarkko Sakkinen , Russell King , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , "Naveen N. Rao" , Anil S Keshavamurthy , Masami Hiramatsu , Luis Chamberlain , Steven Rostedt , Kees Cook , "Peter Zijlstra (Intel)" , Nathan Chancellor , Josh Poimboeuf , Mark Rutland , "Eric W. Biederman" , Marco Elver , Dan Li , Sami Tolvanen , "Russell King (Oracle)" , Nick Desaulniers , Linus Walleij , Chen Zhongjin , Nicolas Pitre , Mark Brown , Luis Machado , Geert Uytterhoeven , Joey Gouly , Masahiro Yamada , Andrew Morton , Andrey Konovalov , Kefeng Wang , Atsushi Nemoto , Guenter Roeck , Dave Anglin , Christophe Leroy , Alexei Starovoitov , Nicholas Piggin , Daniel Axtens , "Aneesh Kumar K.V" , Jordan Niethe , Guo Ren , Anup Patel , Atish Patra , Changbin Du , Heiko Stuebner , Liao Chang , Philipp Tomsich , Wu Caize , Emil Renner Berthing , Alexander Egorenkov , Thomas Richter , Tobias Huschle , Ilya Leoshkevich , Tom Lendacky , Daniel Bristot de Oliveira , Michael Roth , "Kirill A. Shutemov" , Javier Martinez Canillas , Miroslav Benes , =?UTF-8?B?QW5kcsOp?= Almeida , Tiezhu Yang , Dmitry Torokhov , Aaron Tomlin , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-modules@vger.kernel.org Subject: Re: [PATCH] kprobes: Enable tracing for mololithic kernel images Message-Id: <20220612213041.b1ec5d1ec3426e90e669c495@kernel.org> In-Reply-To: References: <20220608000014.3054333-1-jarkko@profian.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: On Wed, 8 Jun 2022 11:19:19 -0700 Song Liu wrote: > On Wed, Jun 8, 2022 at 9:28 AM Ard Biesheuvel wrote: > > > > Hello Jarkko, > > > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen wrote: > > > > > > Tracing with kprobes while running a monolithic kernel is currently > > > impossible because CONFIG_KPROBES is dependent of CONFIG_MODULES. This > > > dependency is a result of kprobes code using the module allocator for the > > > trampoline code. > > > > > > Detaching kprobes from modules helps to squeeze down the user space, > > > e.g. when developing new core kernel features, while still having all > > > the nice tracing capabilities. > > > > > > For kernel/ and arch/*, move module_alloc() and module_memfree() to > > > module_alloc.c, and compile as part of vmlinux when either CONFIG_MODULES > > > or CONFIG_KPROBES is enabled. In addition, flag kernel module specific > > > code with CONFIG_MODULES. > > > > > > As the result, kprobes can be used with a monolithic kernel. > > > > I think I may have mentioned this the previous time as well, but I > > don't think this is the right approach. > > > > Kprobes uses alloc_insn_page() to allocate executable memory, but the > > requirements for this memory are radically different compared to > > loadable modules, which need to be within an arch-specific distance of > > the core kernel, need KASAN backing etc etc. > > I think the distance of core kernel requirement is the same for kprobe > alloc_insn_page and modules, no? This strongly depends on how kprobes (software breakpoint and single-step) is implemented on the arch. For example, x86 implements the so-called "kprobe-booster" which jumps back from the single stepping trampoline buffer. Then the buffer address must be within the range where it can jump to the original address. However, if the arch implements single-step as an instruction emulation, it has no such limitation. As far as I know, arm64 will do emulation for the instructions which change PC register and will do direct execution with another software breakpoint for other instructions. Why I'm using module_alloc() for a generic function, is that can cover the limitation most widely. Thus, if we have CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE flag and kprobes can check it instead of using __weak function, the kprobes may not need to depend on module_alloc() in general. Thank you, > > Thanks, > Song > > > > > This is why arm64, for instance, does not implement alloc_insn_page() > > in terms of module_alloc() [and likely does not belong in this patch > > for that reason] > > > > > > > Is there any reason kprobes cannot simply use vmalloc()? > > -- Masami Hiramatsu (Google) 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 382DBC433EF for ; Sun, 12 Jun 2022 12:31:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ew54o6+2PExGS7MKuI7iwx/IJJU6lQnDg7mzEFiRsao=; b=RqcT0tc4HvFUiF 3XGQ/aSuWxr0tx0NfqZKbrpCAY75NJqAkC7Q6hjII0rBNbldL/jMyLC8XivarH3vDBI/vtjzxamRP jUNnD1JmDyzPpJOFXhmodfXQEZcNXttPVTxIa5TMretz878V1UNMl3hmHBhxgDFBIWJsm3Xiuf1dr euke7b0yo6iea8o2Ch/QHgny9eHyawMEKCO23Q0GJjVWK//vSVI2fkRDPZhvdLw5OEC2bQx2UnvzO jhyWMF6bYGG6DH5ja0JyqwamCG+vgfVgLINjktTs7kcy6CtSvMpJpXGSQpwbbCjnVYW81jOZKZZ56 RcQ6fyzBVJGBrEuvf8UA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o0MkH-00GTg9-Ee; Sun, 12 Jun 2022 12:31:09 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o0MkD-00GTeA-4z; Sun, 12 Jun 2022 12:31:07 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 54BD260EC3; Sun, 12 Jun 2022 12:31:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D957FC34115; Sun, 12 Jun 2022 12:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655037062; bh=75vg2kGshxM5YQM0eTP5ZRYR8Fcv4/li4Jk7t1TdZ38=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ihwcLZes9inwOPuBDeaJye7gcke1UBLU+1VBGf4DvKCK8cnpB6u1SzgyKO4ftcfZG ErQikmY7mpilG3tu8wVrlaHYSKH7Nu92Hyqnw97kzveTBBIVOS3uQ3Jqgu9GFW4w0/ jmS6W7bFFcvW2dOW/LuS2HXtqiKHxLtKSxRKUtWOPvP35PudVpnCQhmoWF/hc9228f gVQ4oyLRAILBu9zA0K+lA3/gxYbMJXzy+bnGsqhl3RfaVq5/VfkBb87Ki9hv8Dkl4s ONjTLXhsGE6D3ntAiXzcwMS2P7ueWXHWUvDCIewbY4eDMY//09jGQh9ejxWsMYhY9O DS4tlNoS30DUQ== Date: Sun, 12 Jun 2022 21:30:41 +0900 From: Masami Hiramatsu (Google) To: Song Liu Cc: Ard Biesheuvel , Jarkko Sakkinen , Linux Kernel Mailing List , Nathaniel McCallum , Jarkko Sakkinen , Russell King , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , "Naveen N. Rao" , Anil S Keshavamurthy , Masami Hiramatsu , Luis Chamberlain , Steven Rostedt , Kees Cook , "Peter Zijlstra (Intel)" , Nathan Chancellor , Josh Poimboeuf , Mark Rutland , "Eric W. Biederman" , Marco Elver , Dan Li , Sami Tolvanen , "Russell King (Oracle)" , Nick Desaulniers , Linus Walleij , Chen Zhongjin , Nicolas Pitre , Mark Brown , Luis Machado , Geert Uytterhoeven , Joey Gouly , Masahiro Yamada , Andrew Morton , Andrey Konovalov , Kefeng Wang , Atsushi Nemoto , Guenter Roeck , Dave Anglin , Christophe Leroy , Alexei Starovoitov , Nicholas Piggin , Daniel Axtens , "Aneesh Kumar K.V" , Jordan Niethe , Guo Ren , Anup Patel , Atish Patra , Changbin Du , Heiko Stuebner , Liao Chang , Philipp Tomsich , Wu Caize , Emil Renner Berthing , Alexander Egorenkov , Thomas Richter , Tobias Huschle , Ilya Leoshkevich , Tom Lendacky , Daniel Bristot de Oliveira , Michael Roth , "Kirill A. Shutemov" , Javier Martinez Canillas , Miroslav Benes , =?UTF-8?B?QW5kcsOp?= Almeida , Tiezhu Yang , Dmitry Torokhov , Aaron Tomlin , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-modules@vger.kernel.org Subject: Re: [PATCH] kprobes: Enable tracing for mololithic kernel images Message-Id: <20220612213041.b1ec5d1ec3426e90e669c495@kernel.org> In-Reply-To: References: <20220608000014.3054333-1-jarkko@profian.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220612_053105_310849_6D7B0757 X-CRM114-Status: GOOD ( 38.35 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, 8 Jun 2022 11:19:19 -0700 Song Liu wrote: > On Wed, Jun 8, 2022 at 9:28 AM Ard Biesheuvel wrote: > > > > Hello Jarkko, > > > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen wrote: > > > > > > Tracing with kprobes while running a monolithic kernel is currently > > > impossible because CONFIG_KPROBES is dependent of CONFIG_MODULES. This > > > dependency is a result of kprobes code using the module allocator for the > > > trampoline code. > > > > > > Detaching kprobes from modules helps to squeeze down the user space, > > > e.g. when developing new core kernel features, while still having all > > > the nice tracing capabilities. > > > > > > For kernel/ and arch/*, move module_alloc() and module_memfree() to > > > module_alloc.c, and compile as part of vmlinux when either CONFIG_MODULES > > > or CONFIG_KPROBES is enabled. In addition, flag kernel module specific > > > code with CONFIG_MODULES. > > > > > > As the result, kprobes can be used with a monolithic kernel. > > > > I think I may have mentioned this the previous time as well, but I > > don't think this is the right approach. > > > > Kprobes uses alloc_insn_page() to allocate executable memory, but the > > requirements for this memory are radically different compared to > > loadable modules, which need to be within an arch-specific distance of > > the core kernel, need KASAN backing etc etc. > > I think the distance of core kernel requirement is the same for kprobe > alloc_insn_page and modules, no? This strongly depends on how kprobes (software breakpoint and single-step) is implemented on the arch. For example, x86 implements the so-called "kprobe-booster" which jumps back from the single stepping trampoline buffer. Then the buffer address must be within the range where it can jump to the original address. However, if the arch implements single-step as an instruction emulation, it has no such limitation. As far as I know, arm64 will do emulation for the instructions which change PC register and will do direct execution with another software breakpoint for other instructions. Why I'm using module_alloc() for a generic function, is that can cover the limitation most widely. Thus, if we have CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE flag and kprobes can check it instead of using __weak function, the kprobes may not need to depend on module_alloc() in general. Thank you, > > Thanks, > Song > > > > > This is why arm64, for instance, does not implement alloc_insn_page() > > in terms of module_alloc() [and likely does not belong in this patch > > for that reason] > > > > > > > Is there any reason kprobes cannot simply use vmalloc()? > > -- Masami Hiramatsu (Google) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1ED2EC433EF for ; Mon, 13 Jun 2022 11:30:30 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4LM8WS4Vhtz3cFT for ; Mon, 13 Jun 2022 21:30:28 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=ihwcLZes; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=mhiramat@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=ihwcLZes; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4LLYvs54Qmz3bkR for ; Sun, 12 Jun 2022 22:31:05 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 54BD260EC3; Sun, 12 Jun 2022 12:31:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D957FC34115; Sun, 12 Jun 2022 12:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655037062; bh=75vg2kGshxM5YQM0eTP5ZRYR8Fcv4/li4Jk7t1TdZ38=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ihwcLZes9inwOPuBDeaJye7gcke1UBLU+1VBGf4DvKCK8cnpB6u1SzgyKO4ftcfZG ErQikmY7mpilG3tu8wVrlaHYSKH7Nu92Hyqnw97kzveTBBIVOS3uQ3Jqgu9GFW4w0/ jmS6W7bFFcvW2dOW/LuS2HXtqiKHxLtKSxRKUtWOPvP35PudVpnCQhmoWF/hc9228f gVQ4oyLRAILBu9zA0K+lA3/gxYbMJXzy+bnGsqhl3RfaVq5/VfkBb87Ki9hv8Dkl4s ONjTLXhsGE6D3ntAiXzcwMS2P7ueWXHWUvDCIewbY4eDMY//09jGQh9ejxWsMYhY9O DS4tlNoS30DUQ== Date: Sun, 12 Jun 2022 21:30:41 +0900 From: Masami Hiramatsu (Google) To: Song Liu Subject: Re: [PATCH] kprobes: Enable tracing for mololithic kernel images Message-Id: <20220612213041.b1ec5d1ec3426e90e669c495@kernel.org> In-Reply-To: References: <20220608000014.3054333-1-jarkko@profian.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Jun 2022 21:27:22 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dan Li , Heiko Stuebner , Linus Walleij , Paul Mackerras , Alexander Gordeev , Javier Martinez Canillas , Geert Uytterhoeven , Catalin Marinas , Christian Borntraeger , Guenter Roeck , =?UTF-8?B?QW5kcsOp?= Almeida , Michael Roth , Nicholas Piggin , Thomas Gleixner , Andrey Konovalov , Nick Desaulniers , Linux Kernel Mailing List , Luis Chamberlain , Masami Hiramatsu , Wu Caize , Guo Ren , Andrew Morton , Mark Rutland , Luis Machado , Atsushi Nemoto < anemo@mba.ocn.ne.jp>, Dave Hansen , Joey Gouly , "James E.J. Bottomley" , linux-s390@vger.kernel.org, Ilya Leoshkevich , Anup Patel , Helge Deller , Anil S Keshavamurthy , Sven Schnelle , Tom Lendacky , Vasily Gorbik , Philipp Tomsich , Dave Anglin , linux-arm-kernel@lists.infradead.org, Daniel Axtens , Nicolas Pitre , Jarkko Sakkinen , "Eric W. Biederman" , "Aneesh Kumar K.V" , Daniel Bristot de Oliveira , Kefeng Wang , Emil Renner Berthing , Jordan Niethe , Atish Patra , Alexei Starovoitov , Will Deacon , Masa hiro Yamada , Jarkko Sakkinen , Sami Tolvanen , "Naveen N. Rao" , Marco Elver , Kees Cook , Steven Rostedt , Nathan Chancellor , "Russell King \(Oracle\)" , Mark Brown , Borislav Petkov , Alexander Egorenkov , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, Nathaniel McCallum , Dmitry Torokhov , "David S. Miller" , "Kirill A. Shutemov" , Tobias Huschle , "Peter Zijlstra \(Intel\)" , "H. Peter Anvin" , sparclinux@vger.kernel.org, Tiezhu Yang , Miroslav Benes , Chen Zhongjin , Ard Biesheuvel , X86 ML , Russell King , linux-riscv@lists.infradead.org, Ingo Molnar , Aaron Tomlin , Albert Ou , Heiko Carstens , Liao Chang , Paul Walmsley , Josh Poimboeuf , Thomas Richter , linux-mips@vger.kernel.org, Changbin Du , Palmer Dabbelt , linuxppc-dev@lists.ozlabs.org, linux-modules@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, 8 Jun 2022 11:19:19 -0700 Song Liu wrote: > On Wed, Jun 8, 2022 at 9:28 AM Ard Biesheuvel wrote: > > > > Hello Jarkko, > > > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen wrote: > > > > > > Tracing with kprobes while running a monolithic kernel is currently > > > impossible because CONFIG_KPROBES is dependent of CONFIG_MODULES. This > > > dependency is a result of kprobes code using the module allocator for the > > > trampoline code. > > > > > > Detaching kprobes from modules helps to squeeze down the user space, > > > e.g. when developing new core kernel features, while still having all > > > the nice tracing capabilities. > > > > > > For kernel/ and arch/*, move module_alloc() and module_memfree() to > > > module_alloc.c, and compile as part of vmlinux when either CONFIG_MODULES > > > or CONFIG_KPROBES is enabled. In addition, flag kernel module specific > > > code with CONFIG_MODULES. > > > > > > As the result, kprobes can be used with a monolithic kernel. > > > > I think I may have mentioned this the previous time as well, but I > > don't think this is the right approach. > > > > Kprobes uses alloc_insn_page() to allocate executable memory, but the > > requirements for this memory are radically different compared to > > loadable modules, which need to be within an arch-specific distance of > > the core kernel, need KASAN backing etc etc. > > I think the distance of core kernel requirement is the same for kprobe > alloc_insn_page and modules, no? This strongly depends on how kprobes (software breakpoint and single-step) is implemented on the arch. For example, x86 implements the so-called "kprobe-booster" which jumps back from the single stepping trampoline buffer. Then the buffer address must be within the range where it can jump to the original address. However, if the arch implements single-step as an instruction emulation, it has no such limitation. As far as I know, arm64 will do emulation for the instructions which change PC register and will do direct execution with another software breakpoint for other instructions. Why I'm using module_alloc() for a generic function, is that can cover the limitation most widely. Thus, if we have CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE flag and kprobes can check it instead of using __weak function, the kprobes may not need to depend on module_alloc() in general. Thank you, > > Thanks, > Song > > > > > This is why arm64, for instance, does not implement alloc_insn_page() > > in terms of module_alloc() [and likely does not belong in this patch > > for that reason] > > > > > > > Is there any reason kprobes cannot simply use vmalloc()? > > -- Masami Hiramatsu (Google)