Remove execute permissions from mappings in exec_map and pipe_map.

[markj]

Summary

They are not needed. I considered also adding prot and maxprot
parameters to kmem_suballoc(), but that doesn't appear to have any
effect on submaps, so I didn't bother.

Reported by: jhb

Test Plan

I used kgdb to examine PTEs in the range managed by the two
submaps and verified that NX was present where it wasn't before.

I audited uses of exec_map and pipe_map in the kernel (exec_map
has some uses in some exotic image activators, though most
uses look like they could be replaced with an allocation of a single
wired page).

[markj]

sys/vm/vm_kern.c

628 ↗

(On Diff #49974)

This should be "maxprot".

[markj]

• "max" -> "maxprot"

[kib]

sys/kern/kern_exec.c

1350 ↗

(On Diff #49975)

This is the only use of the kmap_alloc_wait() function that I am able to find. Why do you think it is useful to add prot and maxprot args to it, instead of hardcoding VM_PROT_RW into the vm_map_insert() call from the function ?

[markj]

sys/kern/kern_exec.c

1350 ↗

(On Diff #49975)

kmap_alloc_wait() is a simple wrapper of vm_map_insert(); it seemed a bit strange to me to bake this policy into the implementation. I don't think it's particularly useful to have the extra arguments, though, so I will change kmap_alloc_wait() instead if you prefer.

[kib]

sys/kern/kern_exec.c

1350 ↗

(On Diff #49975)

The current code hardcodes the policy as well. I was more curious about implied usefulness of the prot/maxprot arguments.

[jhb]

sys/kern/kern_exec.c

1350 ↗

(On Diff #49975)

I do probably find it a bit odd to provide both arguments. I would probably lean towards either hardcoding a RW policy or providing a single 'prot' argument that is used as both 'prot' and 'maxprot', but that is a minor detail.

[markj]

sys/kern/kern_exec.c

1350 ↗

(On Diff #49975)

Ok, I will just hard-code the policy.

[markj]

• Hard-code VM_PROT_RW in kmap_alloc_wait().

[emaste]

LGTM

[jhb]

Thanks for testing and fixing this.