Thread (65 messages) 65 messages, 12 authors, 2023-07-17

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

From: "Andy Lutomirski" <luto@kernel.org>
Date: 2023-07-17 17:24:30
Also in: bpf, linux-arm-kernel, linux-mips, linux-mm, linux-modules, linux-riscv, linux-s390, linux-trace-kernel, lkml, loongarch, netdev, sparclinux


On Mon, Jun 26, 2023, at 10:48 AM, Song Liu wrote:
On Mon, Jun 26, 2023 at 5:31 AM Mark Rutland [off-list ref] wrote:
quoted
[...]
quoted
quoted
So the idea was that jit_text_alloc() will have a cache of large pages
mapped ROX, will allocate memory from those caches and there will be
jit_update() that uses text poking for writing to that memory.

Upon allocation of a large page to increase the cache, that large page will
be "invalidated" by filling it with breakpoint instructions (e.g int3 on
x86)
Does that work on x86?

That is in no way gauranteed for other architectures; on arm64 you need
explicit cache maintenance (with I-cache maintenance at the VA to be executed
from) followed by context-synchronization-events (e.g. via ISB instructions, or
IPIs).
I guess we need:
1) Invalidate unused part of the huge ROX pages;
2) Do not put two jit users (including module text, bpf, etc.) in the
same cache line;
3) Explicit cache maintenance;
4) context-synchronization-events.

Would these (or a subset of them) be sufficient to protect us from torn read?
Maybe?  #4 is sufficiently vague that I can't really interpret it.

I have a half-drafted email asking for official clarification on the rules that might help shed light on this.  I find that this type of request works best when it's really well written :)
Thanks,
Song
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help