You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
KRF_SAFE_WRITE
is currently a no-op on FreeBSD:krf/src/module/freebsd/freebsd.h
Line 5 in 82990c2
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.
The text was updated successfully, but these errors were encountered: