lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Jun 2022 18:41:36 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "hch@....de" <hch@....de>,
        "christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
        "mcgrof@...nel.org" <mcgrof@...nel.org>
CC:     "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>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "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, 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ