Le 29/05/2017 à 00:50, Balbir Singh a écrit :
On Sun, 2017-05-28 at 17:59 +0200, christophe leroy wrote:
Le 25/05/2017 à 05:36, Balbir Singh a écrit :
Today our patching happens via direct copy and
patch_instruction. The patching code is well
contained in the sense that copying bits are limited.
While considering implementation of CONFIG_STRICT_RWX,
the first requirement is to a create another mapping
that will allow for patching. We create the window using
text_poke_area, allocated via get_vm_area(), which might
be an overkill. We can do per-cpu stuff as well. The
downside of these patches that patch_instruction is
now synchornized using a lock. Other arches do similar
things, but use fixmaps. The reason for not using
fixmaps is to make use of any randomization in the
future. The code also relies on set_pte_at and pte_clear
to do the appropriate tlb flushing.
Isn't it overkill to remap the text in another area ?
Among the 6 arches implementing CONFIG_STRICT_KERNEL_RWX (arm, arm64,
parisc, s390, x86/32, x86/64):
- arm, x86/32 and x86/64 set text RW during the modification
x86 uses set_fixmap() in text_poke(), am I missing something?
Indeed I looked how it is done in ftrace. On x86 text modifications are
done using ftrace_write() which calls probe_kernel_write() which doesn't
remap anything. It first calls ftrace_arch_code_modify_prepare() which
sets the kernel text to rw.
Indeed you are right, text_poke() remaps via fixmap. However it looks
like text_poke() is used only for kgdb and kprobe
Christophe
