Implement KRF_SAFE_WRITE for FreeBSD

[woodruffw]

KRF_SAFE_WRITE is currently a no-op on FreeBSD:

https://github.com/trailofbits/krf/blob/82990c258c2e0b555f358b76b21f8781b1f42a54/src/module/freebsd/freebsd.h#L5

We should check whether FreeBSD provides cr0 manipulation functions/macros. If it doesn't, then we should add our own like the ones used in this blog post (under "Disabling CPU write protection").

ccing @roachspray as a source of expertise about write protection/safe locking in FreeBSD.

[hmwildermuth]

Do we need cr0 manipulation at all? The writes to the sysent table are succeeding without complaint as of now.

[woodruffw]

Yeah, I'm not actually certain why it's succeeding.

cpu_setregs should be setting WP on CPU init:

https://github.com/freebsd/freebsd/blob/fd1567d78195bddf8e366a191198eabd11bd7563/sys/amd64/amd64/machdep.c#L655

In any case, it doesn't actually hurt us to add it. But let's deprioritize it for now.

[woodruffw]

This might be related to securelevel:

sysctl -n kern.securelevel
-1

We should find out what other values are supported and whether any of them prevent modification of kernel memory. The page linked above says that at least one level blocks /dev/kmem, but it doesn't say anything about direct access.

[hmwildermuth]

I attempted running the module with kern.securelevel=1, and there were no issues with writing to the sysent table. Functionality was completely normal, no errors came up in dmesg and the program successfully faulted a target.
I doubt that higher values of securelevel would behave differently because according to FreeBSD documentation they add very specific checks and balances.

[woodruffw]

Yeah, makes sense. We can table this for now.