Closed patrick-rivos closed 1 year ago
This PR only affects the case where the page has not yet been faulted in. (The else
case below is for the case that the page has already been faulted in.) Presumably a related change is necessary there?
After you address that concern, we can merge this, and deal with any unforeseen consequences later.
I added in the change to the else clause (just removing the check there). There is definitely the corner case of not allowing changes to vsyscall (which is currently allowed by the current patch), but I want to make sure these changes are somewhat logical before I attempt to address that corner-case.
The man page for mprotect states in the notes section: "On Linux, it is always permissible to call mprotect() on any address in a process's address space (except for the kernel vsyscall area). In particular, it can be used to change existing code mappings to be writable."
Currently, if the page table entry is valid and the new prot is more permissive in any way when compared to the prior one, mprotect fails.
IIUC, This prevents changing an existing mapping to be writeable.
This commit removes that check.