| 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
| ||
|
Date: Wed, 15 Jun 2022 08:37:07 +0200
From: "hch@....de" <hch@....de>
To: "jarkko@...nel.org" <jarkko@...nel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"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 Tue, Jun 14, 2022 at 03:32:38PM +0300, jarkko@...nel.org wrote:
> > 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?
I don't think cloning the code helps anyone. The fact that except
for the eBPF mess everyone uses module_alloc and the related
infrastructure is a feature and not a bug. The interface should
become better than what we have right now, but there is few enough
users that this can be done in one go.
So assuming we really care deeply enough about fancy tracing without
modules (and I'm not sure we do, even if you don't use modules it
doesn't hurt to just build the modules code, I do that all the time
for my test machines), the general approach in your series is the
right one.
Powered by blists - more mailing lists