KPTI: add control from proccontrol(8)

[kib]

Summary

The change consists of four:

• when the pmap with pti disabled (i.e. pm_ucr3 == PMAP_NO_CR3) is activated, tss.rsp0 was not updated. Any interrupt that happen before context switch would use pti trampoline stack for hardware frame but fault handlers are not prepared to this. Correctly update tss.rsp0 for both PMAP_NO_CR3 and pti pmaps. Since the code now duplicates the asm in cpu_switch.S, remove the fragment to update tss.rsp0 from there.
• addition of P_MD_KPTI flag, this is autonomous and probably should be committed unconditionally. The flag controls if the new pmap after exec gets KPTI active.
• addition of procctl(2) MD stuff (this is not complete since it lacks stubs on anything non-amd64).
• addition of procctl(2) and proccontrol(8) knobs for KPTI.

[kib]

Remove unneeded proctree lock acquisition.

Noted by: mjg

[kib]

Switch to pget(), simplify control flow.

[jhb]

This generally looks good to me. Presumably for MFC'ing we'd have to stick the md_flags field at the end of 'struct proc' instead.

sys/sys/procctl.h

61 ↗

(On Diff #54850)

I would probably put the #include earlier in the file to match the style in other headers?

[kib]

Move machine/procctl.h header inclusion up.

[markj]

sys/amd64/include/proc.h

73 ↗

(On Diff #54854)

Does cpu_fork() need to initialize the flags in the child?

[kib]

sys/amd64/amd64/vm_machdep.c

186 ↗

(On Diff #54854)

Markj, look at this line.

[kib]

Use PRIV_IO for proccontrol(KPTI_CTL) instead of PRIV_KMEM_READ. The later is more true, but we do grant this privilege to non-root users on basis that /dev/kmem permission should be used.

Fix nasty bug with handling of PMAP_NO_CR3 thread in pti-enabled environment. I will explain it in updated revision summary since I need it for commit message (shortly, tss.rsp0 was not updated on activation from exec).

[kib]

I was wrong removing the bits to update tss.rsp0 in the context switch asm. If thread uses non-common TSS, then we need to update newly switched TSS' tss.rsp0 as well. While there, rewrite this fragment to avoid jumps.

[kib]

Peter, could you, please, test this ?

The updated proccontrol(1) allows to disable or enable KPTI for future execve(2) of the process and its children. So for instance you can start one batch of stress2 normally, and another using the command like

proccontrol -m kpti -s disable sh <script>

This would make two stress2 runs running in parallel, one with KPTI enabled, another disabled. You can, of course, run a specific program under enabled/disabled mode as well.
It would be most important to check the ldt and io ports tests.

[kib]

Fill missed bits for !amd64 architectures.