Message-ID: <Yqh/5nn0AhdwaCm8@iki.fi>
Date:   Tue, 14 Jun 2022 15:32:38 +0300
From:   "jarkko@...nel.org" <jarkko@...nel.org>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc:     "hch@....de" <hch@....de>,
        "christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
        "mcgrof@...nel.org" <mcgrof@...nel.org>,
        "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
        "paulus@...ba.org" <paulus@...ba.org>,
        "zepan@...eed.com" <zepan@...eed.com>,
        "iii@...ux.ibm.com" <iii@...ux.ibm.com>,
        "deller@....de" <deller@....de>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
        "joey.gouly@....com" <joey.gouly@....com>,
        "anemo@....ocn.ne.jp" <anemo@....ocn.ne.jp>,
        "egorenar@...ux.ibm.com" <egorenar@...ux.ibm.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "bp@...en8.de" <bp@...en8.de>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "x86@...nel.org" <x86@...nel.org>,
        "luis.machado@...aro.org" <luis.machado@...aro.org>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "mbenes@...e.cz" <mbenes@...e.cz>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "jniethe5@...il.com" <jniethe5@...il.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "andreyknvl@...il.com" <andreyknvl@...il.com>,
        "dja@...ens.net" <dja@...ens.net>,
        "liaochang1@...wei.com" <liaochang1@...wei.com>,
        "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
        "huschle@...ux.ibm.com" <huschle@...ux.ibm.com>,
        "will@...nel.org" <will@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "James.Bottomley@...senpartnership.com" 
        <James.Bottomley@...senpartnership.com>,
        "song@...nel.org" <song@...nel.org>,
        "guoren@...nel.org" <guoren@...nel.org>,
        "nathan@...nel.org" <nathan@...nel.org>,
        "dave.anglin@...l.net" <dave.anglin@...l.net>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "atomlin@...hat.com" <atomlin@...hat.com>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
        "anup@...infault.org" <anup@...infault.org>,
        "javierm@...hat.com" <javierm@...hat.com>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "philipp.tomsich@...ll.eu" <philipp.tomsich@...ll.eu>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
        "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
        "yangtiezhu@...ngson.cn" <yangtiezhu@...ngson.cn>,
        "aneesh.kumar@...ux.ibm.com" <aneesh.kumar@...ux.ibm.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "heiko@...ech.de" <heiko@...ech.de>,
        "nathaniel@...fian.com" <nathaniel@...fian.com>,
        "michael.roth@....com" <michael.roth@....com>,
        "rmk+kernel@...linux.org.uk" <rmk+kernel@...linux.org.uk>,
        "Sakkinen, Jarkko" <jarkko@...fian.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "wangkefeng.wang@...wei.com" <wangkefeng.wang@...wei.com>,
        "tmricht@...ux.ibm.com" <tmricht@...ux.ibm.com>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
        "atishp@...shpatra.org" <atishp@...shpatra.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "kernel@...il.dk" <kernel@...il.dk>,
        "ashimida@...ux.alibaba.com" <ashimida@...ux.alibaba.com>,
        "elver@...gle.com" <elver@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mhiramat@...nel.org" <mhiramat@...nel.org>,
        "Keshavamurthy, Anil S" <anil.s.keshavamurthy@...el.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "chenzhongjin@...wei.com" <chenzhongjin@...wei.com>,
        "andrealmeid@...lia.com" <andrealmeid@...lia.com>,
        "changbin.du@...el.com" <changbin.du@...el.com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>
Subject: Re: [PATCH] kprobes: Enable tracing for mololithic kernel images

On Thu, Jun 09, 2022 at 06:41:36PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2022-06-09 at 06:24 -0700, Luis Chamberlain wrote:
> > 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.
> 
> BPF even has multiple uses for text allocation. It has its own
> trampoline feature that puts different type of text in the allocation,
> with its own allocation routine. I looks like there are even more
> little allocators in there.
> 
> So yea, there seems to be a lot of the kernel in the business of
> dynamically generated text, for better or worse. I agree that it needs
> to be done carefully. However, these usages always seem to have the
> same problems (W^X, arch eccentricities, etc). So I don't think we
> should hide away the pieces. Instead we should have something with
> guard rails on it, so they can't get the allocation part wrong.
> 
> But I guess the question here is: what should we do in the meantime? It
> is kind of similar to the questions that came up around the bpf prog
> pack allocator. Should we hold up allocator related work until
> underlying problems are resolved and there is some mature core
> solution?
> 
> Personally I had thought we would need to do some clean switch to a
> much different interface. I still think someday it will be required,
> but it seems to be evolving naturally for the time being.
> 
> Like say for a next step we moved prog pack out of bpf into core code,
> gave it it's own copy of module_alloc(), and then made kprobes use it.
> Then we would have something with improved W^X guard rails, and kprobes
> would not depend on modules anymore. I think maybe it's a step in the
> right direction, even if it's not perfect.

So you're saying that I should (as a first step) basically clone
module_alloc() implementation for kprobes, and future for BPF 
use, in order to get a clean starting point?

BR, Jarkko

Powered by blists - more mailing lists