luxnic.net" , "ebied...@xmission.com"
, "aneesh.ku...@linux.ibm.com"
, "bris...@redhat.com" ,
"wangkefeng.w...@huawei.com" , "ker...@esmil.dk"
, "jniet...@gmail.com" ,
"paul.walms...@sifive.com" , "a...@kernel.org"
, "w...@kernel.org" , "masahi...@kernel.org"
, "Sakkinen, Jarkko" ,
"samitolva...@google.com" ,
"naveen.n@linux.ibm.com" , "el...@google.com"
, "keesc...@chromium.org" ,
"rost...@goodmis.org" , "nat...@kernel.org"
, "rmk+ker...@armlinux.org.uk" ,
"broo...@kernel.org" , "b...@alien8.de" ,
"egore...@linux.ibm.com" , "tsbog...@alpha.franken.de" ,
"linux-par...@vger.kernel.org" ,
"nathan...@profian.com" , "dmitry.torok...@gmail.com"
, "da...@davemloft.net" ,
"kirill.shute...@linux.intel.com" ,
"husc...@linux.ibm.com" , "pet...@infradead.org"
, "h...@zytor.com" ,
"sparcli...@vger.kernel.org" ,
"yangtie...@loongson.cn" , "mbe...@suse.cz"
, "chenzhong...@huawei.com" ,
"a...@kernel.org" , "x...@kernel.org" ,
"li...@armlinux.org.uk" ,
"linux-ri...@lists.infradead.org" ,
"mi...@redhat.com" , "atom...@redhat.com"
, "a...@eecs.berkeley.edu" ,
"h...@linux.ibm.com" , "liaochang1@
huawei.com" , "ati...@atishpatra.org"
, "jpoim...@kernel.org" ,
"tmri...@linux.ibm.com" , "linux-m...@vger.kernel.org"
, "changbin...@intel.com" ,
"pal...@dabbelt.com" , "linuxppc-dev@lists.ozlabs.org"
, "linux-modu...@vger.kernel.org"
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev"
On Thu, Jun 09, 2022 at 06:41:36PM +, 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
