For now, allow mprotect(2) over the guards to succeed regardless of

the requested protection.

The syscall returns success without changing the protection of the
guard.  This is consistent with the current mprotect(2) behaviour on
the unmapped ranges.  More important, the calls performed by libc and
libthr to allow execution of stacks, if requested by the loaded ELF
objects, do the expected change instead of failing on the grow space
guard.

Reviewed by:	alc, markj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
This commit is contained in:
Konstantin Belousov 2017-06-25 23:16:37 +00:00
parent 18f4c9db68
commit 8a89ca9425

View File

@ -2003,6 +2003,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
*/
for (current = entry; current != &map->header && current->start < end;
current = current->next) {
if ((current->eflags & MAP_ENTRY_GUARD) != 0)
continue;
if (current->eflags & MAP_ENTRY_IS_SUB_MAP) {
vm_map_unlock(map);
return (KERN_INVALID_ARGUMENT);