Message-ID: <YqH0iEgsi6+bwS3x@bombadil.infradead.org>
Date:   Thu, 9 Jun 2022 06:24:24 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Christoph Hellwig <hch@....de>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Song Liu <song@...nel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Guo Ren <guoren@...nel.org>,
        Jarkko Sakkinen <jarkko@...fian.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nathaniel McCallum <nathaniel@...fian.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Helge Deller <deller@....de>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Kees Cook <keescook@...omium.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Marco Elver <elver@...gle.com>,
        Dan Li <ashimida@...ux.alibaba.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Chen Zhongjin <chenzhongjin@...wei.com>,
        Nicolas Pitre <nico@...xnic.net>,
        Mark Brown <broonie@...nel.org>,
        Luis Machado <luis.machado@...aro.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Joey Gouly <joey.gouly@....com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Atsushi Nemoto <anemo@....ocn.ne.jp>,
        Guenter Roeck <linux@...ck-us.net>,
        Dave Anglin <dave.anglin@...l.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Daniel Axtens <dja@...ens.net>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Jordan Niethe <jniethe5@...il.com>,
        Anup Patel <anup@...infault.org>,
        Atish Patra <atishp@...shpatra.org>,
        Changbin Du <changbin.du@...el.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Liao Chang <liaochang1@...wei.com>,
        Philipp Tomsich <philipp.tomsich@...ll.eu>,
        Wu Caize <zepan@...eed.com>,
        Emil Renner Berthing <kernel@...il.dk>,
        Alexander Egorenkov <egorenar@...ux.ibm.com>,
        Thomas Richter <tmricht@...ux.ibm.com>,
        Tobias Huschle <huschle@...ux.ibm.com>,
        Ilya Leoshkevich <iii@...ux.ibm.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Michael Roth <michael.roth@....com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Miroslav Benes <mbenes@...e.cz>,
        André Almeida <andrealmeid@...lia.com>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Aaron Tomlin <atomlin@...hat.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        sparclinux <sparclinux@...r.kernel.org>,
        linux-modules@...r.kernel.org
Subject: Re: [PATCH] kprobes: Enable tracing for mololithic kernel images

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:
> > 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

Powered by blists - more mailing lists