procctl(2) and proccontrol(1): add W^X control

[kib]

I checked that go binaries that have no PT_GNU_STACK segment and no elfctl note to disable wxorx for the image, do start with kern.elf64.allow_wx=0 and 'proccontrol -m wxorx -s disable <go program>'

[markj]

lib/libc/sys/procctl.2

618

622

629

643

644

648

653

654

708

711

I would perhaps s/like JIT// and add another sentence along the lines of, "This may be legitimately required by some programs, such as JIT compilers."

sys/kern/kern_procctl.c

605

I think you need a P_WEXIT check here as you have below.

643

What's the point of unlocking the proc at all?

[kib]

sys/kern/kern_procctl.c

643

vmspace_acquire_ref() potentially results in the call to vmspace_free()->vmspace_dofree()->VM locking (e.g. sleepable vm map lock take)

[kib]

Regularize prologue in wxorx_status/ctl, check P_WEXIT and assert process lock.
Man page language fixes.

[markj]

lib/libc/sys/procctl.2

608

[emaste]

lib/libc/sys/procctl.2

606

I'm concerned by the different sense of the two flags, WXORX being enabled is equivalent to allow_wx=0.

617

this is why I desire positive sense flags (and why sysctl(9) recommends positive sense): this *_DISABLE flag enables something, which can be confusing

622

and *_ENABLE_* prevents something

[markj]

lib/libc/sys/procctl.2

617

This problem exists no matter what, it's just a question of what you're disabling: the mitigation, or the ability to create writeable, executable mappings. PROC_WXORX_DISABLE and PROC_WXORX_ENABLE_ON_EXEC both clearly refer to the mitigation.

A more explicit naming scheme would be to have PROC_PERMIT_WX_MAPPINGS and PROC_PERMIT_WX_MAPPINGS_ON_EXEC or something similar. That is, instead of referring to the mitigation, refer to the underlying capability. I think I slightly prefer that approach since it's a bit clearer and agrees with the sysctl.

[kib]

Rename to PROC_WXMAP, PROC_WX_MAPPINGS_PERMIT, and PROC_WX_MAPPINGS_DISALLOW_EXEC, as suggested by Markj.

[markj]

usr.bin/proccontrol/proccontrol.1

75