How to forbid user space and kernel executable pages from becoming writable?

Lev Olshvang levonshe at
Sat Jan 5 10:30:01 EST 2019

I am researching this issue and I am confused with the finding

Some articles, ex
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 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.


More information about the Kernelnewbies mailing list