Re: [PATCH] kprobes: Enable tracing for mololithic kernel images

[jarkko@xxxxxxxxxx]

On Wed, Jun 15, 2022 at 08:37:07AM +0200, hch@xxxxxx wrote:
> On Tue, Jun 14, 2022 at 03:32:38PM +0300, jarkko@xxxxxxxxxx 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.

OK, thanks for the elaboration!

However I bake it, I doubt that next version is going to be the final
version, given all the angles. Therefore, I mostly Christophe's
suggestions on compilation flags, and also split this into per-arch
patches.

That should be at least to the right direction.

BR, Jarkko