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

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

From: Nadav Amit <hidden>
Date: 2023-06-05 21:11:47
Also in: bpf, linux-arm-kernel, linux-mips, linux-modules, linux-riscv, linux-s390, linux-trace-kernel, lkml, loongarch, netdev, sparclinux

On Jun 5, 2023, at 9:10 AM, Edgecombe, Rick P [off-list ref] wrote:

On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
quoted
On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
quoted
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
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 :)
I don't know the details, but previously there was some strong dislike
of CR0.WP toggling. And now there is also the problem of CET. Setting
CR0.WP=0 will #GP if CR4.CET is 1 (as it currently is for kernel IBT).
I guess you might get away with toggling them both in some controlled
situation, but it might be a lot easier to hack up then to be made
fully acceptable. It does sound much more efficient though.
Thanks for highlighting this issue. I understand the limitations of
CR0.WP. There is also always the concerns that without CET or other
control flow integrity mechanism, someone would abuse (using ROP/JOP)
functions that clear CR0.WP…
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help