I am researching this issue and I am confused with the finding Some articles, ex https://shanetully.com/2013/12/writing-a-self-mutating-x86_64-c-program/ state that mprotect() can change protection of executable section. As I understanf pte entry has page protection bits set to RO so mprotect should change pte which is loaded to MMU/TLB. Why kernel can not refuse do perform this mprotect call(). Whu we do norhave kernel config options to forbid user-space mutable code as security feature?
From the other side, when run-time linker or elf_loader loads the executable it uses MAP_DENYWRITE which protect executable file from being overwritten.
But writing to executable text will make page dirty and require the write-back which is disabled by MAP_DENYWRITE. (or it might be disable for other processes except current, I am not sure?) To add to the confusion, the following quote from the LWN articlle https://lwn.net/Articles/422487/ about CONFIG_DEBUG_SET_MODULE_RONX "Marking the kernel module pages as RO and/or NX is important not only because it is consistent with how the rest of the kernel pages are handled" Digging dipper I see that ARM since kernel version 4.11 has CONFIG_STRICT_KERNEL_RWX , and as I understand it is enforced in hardware. But I am not sure that some variant of pte_clear(), pte_mkexec(0 can not disable it. So let me cut to final qiestion: Suppose I want to cut off dynamic code instrumentation, like ftrace and friends. Is it achievable at least at ARM architecture to enforce RO+X at hardware or kernel? Thanks to all folks for reading till this point. Regards Lev