Your text seems somewhat backwards, because if you can't open it, it doesn't matter if it is read-only, it is read-not.
>Neither mem(4) nor securelevel(7) tell exactly which operations are >allowed on these devices at which security level. > >The utility cbmem from the new sysutils/coreboot-utils port opens >/dev/mem read-only and reading is possible at all security levels, as >long as the sysctl kern.allowkmem is non-zero. > >I verified this with cbmem. > >Writing however is only possible at an insecure security level. > >intelmetool from coreboot-utils (not packaged yet) does write to >/dev/mem and I verified that writing is only possible at securelevel -1 >and 0. kern.allowkmem does not matter. > >Diff below explicity states this in securelevel(7); note how I >intentionally document those semantics in this MI manual rather then the >various copies of MD mem(4). > >Feedback? OK? > > >Index: share/man/man7/securelevel.7 >=================================================================== >RCS file: /cvs/src/share/man/man7/securelevel.7,v >retrieving revision 1.31 >diff -u -p -r1.31 securelevel.7 >--- share/man/man7/securelevel.7 21 Aug 2019 20:44:09 -0000 1.31 >+++ share/man/man7/securelevel.7 19 Jan 2020 16:14:52 -0000 >@@ -66,7 +66,10 @@ securelevel may no longer be lowered exc > .Pa /dev/mem > and > .Pa /dev/kmem >-cannot be opened >+are read-only and can only be opened if the >+.Va kern.allowkmem >+.Xr sysctl 8 >+variable is set > .It > raw disk devices of mounted file systems are read-only > .It > >
