Thread (55 messages) 55 messages, 10 authors, 2023-07-20

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

From: Mike Rapoport <rppt@kernel.org>
Date: 2023-06-05 08:12:17
Also in: bpf, linux-arm-kernel, linux-mips, linux-riscv, linux-s390, linux-trace-kernel, linuxppc-dev, lkml, loongarch, netdev, sparclinux

On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
On Thu, 1 Jun 2023 16:54:36 -0700
Nadav Amit [off-list ref] wrote:
quoted
quoted
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.  
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help