Messages in this thread | | | Date | Mon, 5 Jun 2023 11:11:43 +0300 | From | Mike Rapoport <> | Subject | Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX |
| |
On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote: > On Thu, 1 Jun 2023 16:54:36 -0700 > Nadav Amit <nadav.amit@gmail.com> wrote: > > > > The way text_poke() is used here, it is creating a new writable alias > > > and flushing it for *each* write to the module (like for each write of > > > an individual relocation, etc). I was just thinking it might warrant > > > some batching or something.
> > I am not advocating to do so, but if you want to have many efficient > > writes, perhaps you can just disable CR0.WP. Just saying that if you > > are about to write all over the memory, text_poke() does not provide > > too much security for the poking thread.
Heh, this is definitely and easier hack to implement :)
> Batching does exist, which is what the text_poke_queue() thing does.
For module loading text_poke_queue() will still be much slower than a bunch of memset()s for no good reason because we don't need all the complexity of text_poke_bp_batch() for module initialization because we are sure we are not patching live code.
What we'd need here is a new batching mode that will create a writable alias mapping at the beginning of apply_relocate_*() and module_finalize(), then it will use memcpy() to that writable alias and will tear the mapping down in the end.
Another option is to teach alternatives to update a writable copy rather than do in place changes like Song suggested. My feeling is that it will be more intrusive change though.
> -- Steve >
-- Sincerely yours, Mike.
| |