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
