How you have grown ... sxadm

I remember i have first talked at a Solaris day in the Vienna Urania about sxadm for security extension administration. At that time we had one security extension and having an own administration program looked a little bit over the top for it. The single existing extension was for ASLR or “address space layout randomization”.

root@solaris:/# sxadm info
EXTENSION STATUS CONFIGURATION
aslr                enabled (tagged-files)         system default (default)

And this was it … in 2013. Well, things have grown significantly since and so sxadm makes a lot more sense. Now it’s a central place for checking the state and partly to control the state of a number of security mechanisms and mitigations inside of Solaris. This is the current output of the system on a x86 system.

aslr                enabled (tagged-files)        u-c--
ibpb                not supported                 -----
ibrs                not supported                 -----
if_pschange_mc_no   not supported                 -----
kpti                enabled                       -kcr-
l1df                enabled                       -kcr-
md_clear            enabled                       -kcr-
mds_no              not supported                 -----
nxheap              enabled (tagged-files)        u-c--
nxstack             enabled (all)                 u-c--
rdcl_no             not supported                 -----
rsbs                enabled                       -kcr-
smap                not supported                 -----
ssbd                not supported                 -----
taa_no              not supported                 -----
tsx_disable         not supported                 -----
umip                not supported                 -----

The list looks differenly on a SPARC system because for example ADI isn’t available on x86. The job of sxadm got a little bit different. For some extensions it’s more like a status report, not a mechanism to enable or disable them, as they are either always enabled, enabled or disabled elsewhere or just show the state of things. I will cite the public man page for the following list.

A first group of extensions manages Solaris feature (albeit they may use CPU features). Some of the features are quite old like nxheap and nxstack, which were managed by /etc/system in the past.

• ADIHEAP: ADI based protections for heap allocators
• ADISTACK: ADI based protections for stacks
• KADI: ADI based protections for kernel heap
• ASLR: Address Space Layout Randomization
• NXHEAP: Non-Executable Heap
• NXSTACK Non-Executable Stack

A number of other extensions are meant to manage the mitigation against vulnerabilities of CPUs. Please consult the sxadm man page for further information.

• HW_BTI: Hardware BTI Mitigation
• IBPB: Indirect Branch Prediction Barrier
• IBRS: Indirect Branch Restricted Speculation
• KPTI: Kernel Page Table Isolation
• L1DF: Level 1 Data Cache Flush
• MD_CLEAR: Microarchitectural Data Sampling Avoidance Mitigation
• RSBS: Return Stack Buffer Speculation Mitigation
• SMAP: Supervisor Mode Access Prevention
• SSBD: Speculative Store Bypass Disable
• TSX_DISABLE: Intel TSX Asynchronous Abort (TAA) Avoidance Mitigation by disabling TSX
• UMIP: User-Mode Instruction Prevention
• IF_PSCHANGE_MC_NO: Machine Check Error on Page Size Change Mitigation

There are a number of extensions that are meant to show you that some mitigations are not active because your CPU isn’t vulnerable.

• MDS_NO Microarchitectural Data Sampling Hardware Avoidance Mitigation. This one is enabled when you don’t need the mitigation mechanism provider by MD_CLEAR because you CPU isn’t vulnerable.
• RDCL_NORogue Data Cache Avoidance Mitigation. This is as well only enabled when your CPU isn’t vulnerable.
• TAA_NO>: Intel TSX Asynchronous Abort (TAA) Hardware Avoidance Mitigation. This is only enabled, when your CPU isn’t vulnerable and it supports TSX.