How to forbid user space and kernel executable pages from becoming writable?
Lev Olshvang
levonshe at yandex.com
Sat Jan 5 10:30:01 EST 2019
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
More information about the Kernelnewbies
mailing list