Re: [PATCH] kprobes: Enable tracing for mololithic kernel images
From: Luis Chamberlain <mcgrof@kernel.org>
Date: 2022-06-09 13:24:56
Also in:
linux-mips, linux-modules, linux-riscv, linux-s390, lkml, sparclinux
l@kernel.org>, Masahiro Yamada [off-list ref], Jarkko Sakkinen [off-list ref], Sami Tolvanen [off-list ref], "Naveen N. Rao" [off-list ref], Marco Elver [off-list ref], Kees Cook [off-list ref], Steven Rostedt [off-list ref], Nathan Chancellor [off-list ref], "Russell King \(Oracle\)" [off-list ref], Mark Brown [off-list ref], Borislav Petkov [off-list ref], Alexander Egorenkov [off-list ref], Thomas Bogendoerfer [off-list ref], Parisc List [off-list ref], Nathaniel McCallum [off-list ref], Dmitry Torokhov [off-list ref], "David S. Miller" [off-list ref], "Kirill A. Shutemov" [off-list ref], Tobias Huschle [off-list ref], "Peter Zijlstra \(Intel\)" [off-list ref], "H. Peter Anvin" [off-list ref], sparclinux [off-list ref], Tiezhu Yang [off-list ref], Miroslav Benes <mbenes@s use.cz>, Chen Zhongjin [off-list ref], Ard Biesheuvel [off-list ref], the arch/x86 maintainers [off-list ref], Russell King [off-list ref], linux-riscv [off-list ref], Ingo Molnar [off-list ref], Aaron Tomlin [off-list ref], Albert Ou [off-list ref], Heiko Carstens [off-list ref], Liao Chang [off-list ref], Paul Walmsley [off-list ref], Josh Poimboeuf [off-list ref], Thomas Richter [off-list ref], "open list:BROADCOM NVRAM DRIVER" [off-list ref], Changbin Du [off-list ref], Palmer Dabbelt [off-list ref], linuxppc-dev [off-list ref], linux-modules@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" [off-list ref] On Thu, Jun 09, 2022 at 05:48:52AM +0200, Christoph Hellwig wrote:
On Wed, Jun 08, 2022 at 01:26:19PM -0700, Luis Chamberlain wrote:quoted
No, that was removed because it has only one user.That is only part of the story. The other part is that the overall kernel simply does not have any business allocating exutable memory. Executable memory is a very special concept for modules or module-like code like kprobes, and should not be exposed as a general concept.
It is not just modules and kprobes, it is also ftrace and bpf too now. So while it should not be used everywhere calling it module_alloc() is just confusing at this point. Likewise, module_alloc_huge() is being proposed too and I'd rather we deal with this properly in aligment of taking care of the rename as well. If the concern is to restrict access we can use the module namespace stuff so to ensure only intended users get access to it.
Especially as executable memory really should not also be writable for security reasons. In other words, we should actually never allocate executable memory, every. We might seal memory and then mark it executable after having written to it, which is how modules and kprobes are implemented on all modern Linux ports anyway.
The respective free *should* do the executable bits, and there is no generic way to do this for all archs and so it is open coded today. In fact some architectures need further work / help and so split up the module data and exect already on v5.19+ with the new ARCH_WANTS_MODULES_DATA_IN_VMALLOC. See this thread for details: https://lkml.kernel.org/r/Yo1XTN441qbNTLGR@bombadil.infradead.org Doing this work is not easy, but if we're going to do it, it must be done right. Luis