svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
sxadm(8)
sxadm(8) System Administration Commands sxadm(8)
NAME
sxadm - manage Solaris security extensions configuration
SYNOPSIS
sxadm enable [-c property=value[,property=value,...]]
extension[,extension,...]
sxadm exec [-i] [-s extension=value,...] command
sxadm delcust [extension,...]
sxadm disable extension[,extension,...]
sxadm get [-p] [-o field[,...]] property[,...] [extension]
sxadm help [subcommand]
sxadm set property=value[,property=value,...] extension
sxadm status [-p] [-o field[,...]] [extension]
DESCRIPTION
The sxadm command configures and provides information regarding Solaris
security extensions.
The sxadm exec subcommand provides for enabling or disabling security
extensions for a specific command. These extensions apply to the asso‐
ciated process, and can be inherited by any child process using the -i
option. See SECURITY EXTENSIONS.
All other sxadm subcommands configure and provide information regarding
system level security extensions. These extensions apply both to global
zones and non-global zones.
Security extensions for a process are determined by exec(2), and become
effective for a process from that point forward. Extensions persist for
the lifetime of the process until the process exits or calls exec(2)
again. System level extensions can affect all processes. Process level
extensions affect individual processes, and are inherited by any child
processes, providing the child process is not privileged. See SECURITY
EXTENSIONS.
Individual executables can be tagged with security extension require‐
ments when built with ld(1). This tagging ensures the associated
process requirements are met regardless of any system level extensions.
Executables with tagged security extensions can be overridden with
process level extensions. See EXECUTABLE TAGGED EXTENSIONS.
Some security extensions restrict an application, providing defenses
that constrain borderline behavior. As a consequence, some existing ap‐
plications may fail, or experience a performance degradation, when se‐
curity extensions are applied. Generally, newer defenses are more
likely to cause application failure. Over time, as a class of protec‐
tion becomes more mainstream, programming practices are influenced, and
failures due to applying security extensions diminish.
Some security extensions may affect performance, by enabling additional
checks or reducing the usage of certain caches and buffers. System ad‐
ministrators may need to choose between performance and security de‐
pending on the requirements of their environment.
SECURITY EXTENSIONS
The following security extensions are available. These extensions may
reduce the chances of attackers finding known entry points, planting
exploitation code in locations that can later be executed, or taking
advantage of CPU implementations.
ADIHEAP - ADI based protections for heap allocators
Application Data Integrity is a feature introduced with SPARC M7
processors that allow ranges of memory to be tagged with unique
identifiers. See adi(7). These identifiers can be used to automati‐
cally detect invalid reads and writes via pointers with non-match‐
ing identifiers. Heap allocators may use this feature to reliably
detect adjacent buffer overflows and statistically defend against
stray pointers and use-after-free.
ADI is a powerful technology, but can be incompatible with applica‐
tions that do low level address computations. In particular, since
pointers are tagged, an application relying on pointer math needs
to first normalize the pointer. In addition, accesses beyond buffer
limits are also detected as fatal. Some applications are known to
use these accesses as designed optimizations and can fail under
ADI. If an application has run successfully under a memory checker
(for example, valgrind), there is a fair chance that it won't show
these problems. For these reasons, the 'all' model for ADIHEAP is
not supported, and extra care should be taken while testing appli‐
cations that enable ADIHEAP through binary tagging.
The ADIHEAP extension is available only from certain memory alloca‐
tors and only on SPARC systems that support ADI.
ADISTACK - ADI based protections for stacks
ADI identifiers can be used to enable the automatic detection of
buffer overflows that overwrite the register save area of a stack
frame when the save area contains valid contents.
Some applications or interpreted languages may intentionally read
or modify their own stack directly. For this reason, the 'all'
model for ADISTACK is not supported, and extra care should be taken
while testing applications that enable ADISTACK through binary tag‐
ging.
The ADISTACK extension is available only on SPARC systems that sup‐
port ADI.
ASLR - Address Space Layout Randomization
ASLR activates the randomization of the location of key areas of
the process, such as the stack, brk-based heap, and memory segment
mappings. The memory mappings of an application that is built as a
position-independent executable are also randomized under ASLR.
BTC_NO - Branch Type Confusion Mitigation
BTC_NO is a readonly extension that is only enabled on CPUs that
are not vulnerable to the Branch Type Confusion vulnerabilities in
CVE-2022-23825.
FB_CLEAR - Fill Buffer Clear Mitigation
FB_CLEAR is a mitigation that explicitly overwrites fill buffers to
clear no longer needed data as part of the mitigation for the Fill
Buffer Stale Data Propagator (FBSDP) and Device Register Partial
Write (DRPW, CVE-2022-21166) for Intel CPUs only. This prevents un‐
wanted or stale data from being propagated to a location where it
could be read or sampled by a potentially malicious process. It is
enabled by default on systems where it is required and supported.
Some Intel CPUs may allow this mitigation to be disabled. On those
CPUs FB_CLEAR can be configured through sxadm, otherwise FB_CLEAR
will be a readonly extension.
A reboot is required after enabling or disabling FB_CLEAR for the
changes to take effect.
FBSDP_NO - Fill Buffer Stale Data Propagator Mitigation
FBSDP_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to the Fill Buffer Stale Data Propagator (FBSDP)
vulnerabilities that are mitigated in software by the FB_CLEAR ex‐
tension.
Note -
On Intel CPUs that have the FBSDP_NO mitigation enabled, the
FB_CLEAR extension will always be enabled as a readonly exten‐
sion.
GDS - Gather Data Sampling
GDS is a mitigation for the Gather Data Sampling vulnerabilities
for Intel CPUs only (CVE-2022-40982). In some situations after a
gather instruction performs certain types of loads to memory a ma‐
licious process may be able to use this type of instruction to in‐
fer stale data from previously used vector registers.
This mitigation is enabled by default on systems where it is re‐
quired and supported. When it is enabled some workloads might expe‐
rience lower performance.
A reboot is required after enabling or disabling GDS for the
changes to take effect.
GDS_NO Gather Data Sampling Mitigation
GDS_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to the Gather Data Sampling (GDS) vulnerabilities in
CVE-2022-40982 that are mitigated by the GDS extension.
Note -
On Intel CPUs that have the GDS_NO mitigation enabled, the GDS
extension will always be enabled as a readonly extension.
HW_BTI - Hardware BTI Mitigation
HW_BTI provides hardware-based mitigation for CVE-2017-5715 (Branch
Target Injection, Spectre Variant 2) for SPARC CPUs. When enabled,
some applications might experience lower performance.
Note -
sxadm(8) only displays the current state of HW_BTI. Enabling or
disabling HW_BTI is controlled by the ILOM interface. See the Or‐
acle ILOM Administrator's Guide for Firmware Release 4.0.x for
more information. A host reboot is required to make changes.
IBPB - Indirect Branch Prediction Barrier
IBPB is a mitigation for CVE-2017-5715 for x86 CPUs. It is used in
the kernel to guarantee that older indirect branches cannot influ‐
ence predictions of indirect branches in the future. It is enabled
by default on systems where it is required and supported. When it
is enabled some applications might experience lower performance.
A reboot is required after enabling or disabling IBPB for the
changes to take effect.
IBRS - Indirect Branch Restricted Speculation
IBRS is a mitigation for CVE-2017-5715 for x86 CPUs. It is called
on every entry into the kernel and restricts the speculation of in‐
direct branches. It is enabled by default on systems where it is
required and supported. When it is enabled some applications might
experience lower performance.
A reboot is required after enabling or disabling IBRS for the
changes to take effect.
IF_PSCHANGE_MC_NO - Machine Check Error on Page Size Change Mitigation
IF_PSCHANGE_MC_NO is a readonly extension that is enabled only if
the CPU is not vulnerable to the Machine Check Error on Page Size
Change (aka IFU) vulnerability (CVE-2018-12207).
KADI - ADI based protections for kernel heap
KADI catches memory corruption in the kernel heap using Application
Data Integrity. KADI provides protection against buffer overflows,
use-after-frees, use-after-reallocs, and double frees.
A reboot is required after enabling or disabling KADI for the
changes to take effect.
KADI is a development-only feature to be used as a debugging aid by
developers of device drivers and other kernel modules. It may de‐
crease system stability, so is not recommended for use on produc‐
tion systems at this time. A future release may declare KADI suit‐
able for production deployment.
KPTI - Kernel Page Table Isolation
KPTI isolates kernel page tables from user space processes to re‐
duce the opportunity for kernel data leakage. On Intel CPUs this
can mitigate CVE-2017-5754 Rogue Data Cache Load (RDCL) and other
vulnerabilities.
KPTI is always enabled and can not be disabled on SPARC systems.
KPTI is enabled by default on x86 systems. A reboot is required on
x86 systems after enabling or disabling KPTI for the changes to
take effect.
L1DF - Level 1 Data Cache Flush
L1DF is a mitigation for CVE-2018-3646 for Intel CPUs only. It
flushes sensitive data from the L1 data cache to prevent an un‐
trusted guest virtual machine from inferring data from other guest
virtual machines. This flush is performed every time the host sys‐
tem enters a virtual machine (VM entry). As part of this mitigation
disabling hyper-threading (HT) while running virtual machines is
strongly recommended.
Note -
While this mitigation is only needed when running non-trusted
kernel zones, full mitigation also requires disabling hyper-
threading (HT).
This mitigation is enabled by default on systems where it is re‐
quired and supported.
A reboot is required after enabling or disabling L1DF for the
changes to take effect.
MD_CLEAR - Microarchitectural Data Sampling Avoidance
MD_CLEAR is a mitigation for the Microarchitectural Data Sampling
(MDS) series of vulnerabilities for Intel CPUs only. The vulnera‐
bilities are CVE-2018-12126 Microarchitectural Store Buffer Data
Sampling (MSBDS), CVE-2018-12130 Microarchitectural Fill Buffer
Data Sampling (MFBDS), CVE-2018-12127 Microarchitectural Load Port
Data Sampling (MLPDS), CVE-2019-11091 Microarchitectural Data Sam‐
pling Uncacheable Memory (MDSUM). The mitigation overwrites the
store and fill buffers on the logical processors that are affected
by MDS.
Note -
Full mitigation also requires disabling hyper-threading (HT).
This mitigation is enabled by default on systems where it is re‐
quired and supported.
A reboot is required after enabling or disabling MD_CLEAR for the
changes to take effect.
MDS_NO - Microarchitectural Data Sampling Avoidance Mitigation
MDS_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to the Microarchitectural Data Sampling (MDS) series
of vulnerabilities that are mitigated in software by the MD_CLEAR
extension.
Note -
On Intel CPUs that have the MDS_NO mitigation enabled, the
MD_CLEAR extension will always be enabled as a readonly exten‐
sion.
NXHEAP - Non-Executable Heap
NXHEAP prevents pages allocated for the process heap from being ex‐
ecutable.
NXSTACK - Non-Executable Stack
NXSTACK prevents pages allocated for the process stack from being
executable. Backward compatibility with legacy /etc/system,
noexec_user_stack and noexec_user_stack_log settings is maintained,
although such controls are deprecated and sxadm should be used in‐
stead.
PSDP_NO - Primary Stale Data Propagator Mitigation
PSDP_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to Primary Stale Data Propagator (PSDP) vulnerabili‐
ties.
RFDS_CLEAR - Register File Data Sampling
RFDS_CLEAR is a mitigation for the Register File Data Sampling
(RFDS) vulnerabilities found in Intel CPUs (CVE-2023-28746). The
mitigation will overwrite stale register values on the processors
that are affected by RFDS.
This mitigation is enabled by default on systems where it is re‐
quired and supported.
A reboot is required after enabling or disabling RFDS_CLEAR for the
changes to take effect.
RFDS_NO - Register File Data Sampling Mitigation
RFDS_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to Register File Data Sampling (RFDS) vulnerabili‐
ties (CVE-2023-28746).
RDCL_NO - Rogue Data Cache Avoidance Mitigation
RDCL_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to the Rogue Data Cache Load (RDCL) and Microarchi‐
tectural Fill Buffer Data Sampling (MFBDS) vulnerabilities
(CVE-2017-5754, CVE-2018-3646 and CVE-2018-12130).
Note -
Intel CPUs that have the RDCL_NO mitigation enabled also have the
L1DF vulnerability (CVE-2018-3646) mitigated by the CPU. On these
CPUs the L1DF extension will always be enabled as a readonly ex‐
tension.
RSBS - Return Stack Buffer Speculation Mitigation
RSBS is a mitigation for CVE-2018-15572. Enabled by default, it re‐
stricts speculation based on the Return Stack Buffer state.
RSBS also mitigates CVE-2022-26373 in systems hosting kernel zones
on affected Intel processors.
RSBS is always enabled on SPARC systems and cannot be disabled.
On x86 systems, RSBS may be enabled or disabled. A reboot is re‐
quired for the change to take effect.
SBPB - Selective Branch Predictor Barrier Mitigation
SBPB is a mitigation for CVE-2023-20569 for AMD CPUs. It is used in
the kernel to prevent the processor from using older indirect
branch target predictions to influence future indirect branch pre‐
dictions.
Note -
Full mitigation also requires the IBPB mitigation to be supported
and enabled.
This mitigation is enabled by default on systems where it is re‐
quired and supported. When it is enabled some applications might
experience lower performance.
A reboot is required after enabling or disabling SBPB for the
changes to take effect.
SMAP - Supervisor Mode Access Prevention
SMAP is a mechanism to disallow supervisor mode execution of text
mapped only in userland on x86 CPUs. It is enabled by default when
it is supported by the hardware. Certain applications or drivers
can fail when SMAP is enabled.
A reboot is required after enabling or disabling SMAP for the
changes to take effect.
SMEP - Supervisor Mode Execution Prevention
SMEP is a mechanism on supported x86 CPUs to prevent code from user
accessible memory pages from being executed by the kernel. It is a
readonly extension that is only enabled if it is supported by the
hardware.
SRSO_NO - Speculative Return Stack Overflow Mitigation
SRSO_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to any of the Speculative Return Stack Overflow
(SRSO) vulnerabilities (CVE-2023-20569) that are mitigated in soft‐
ware by the SBPB extension.
Note -
On AMD CPUs that have the SRSO_NO mitigation enabled, the SBPB
extension will always be enabled as a readonly extension.
SRSO_USER_KERNEL_NO - Speculative Return Stack Overflow User/Kernel
Mitigation
SRSO_USER_KERNEL_NO is a readonly extension that is only enabled if
the CPU is not vulnerable to user space to kernel space boundary
crossings that are part of the Speculative Return Stack Overflow
(SRSO) vulnerabilities in CVE-2023-20569.
Note -
Full SRSO mitigation also requires SBPB to be enabled on affected
systems.
SSBD - Speculative Store Bypass Disable
SSBD is a mitigation for CVE-2018-3639. It restricts loads from
speculating around older stores. It is enabled by default on sys‐
tems where it is required and supported. When enabled, some appli‐
cations might experience lower performance.
On SPARC, sxadm(8) only displays the current state of SSBD. En‐
abling or disabling SSBD can be done on Fujitsu SPARC systems that
support SSBD via an XSCF command. See XSCF Reference Manual of your
system for more information. A host reboot is required to make
changes.
On x86 systems, SSBD is enabled per-process, either by tagging the
executable with the ssbd elf tag (see ld(1)) or by executing the
process via the sxadm command and enabling the feature.
On affected Intel systems with the 2021.2 IPU or later microcode
updates, the SSBD extension also enables the Predictive Store For‐
warding Disable (PSFD) mitigation for CVE-2021-0145.
SBDR_SSDP_NO - Shared Buffer Data Read and Sideband Stale Data Propaga‐
tor Mitigation
SBDR_SSDP_NO is a readonly extension that is only enabled if the
CPU is not vulnerable to either the Shared Buffer Data Read (SBDR,
CVE-2022-21123) or the Sideband Stale Data Propagator (SSDP) vul‐
nerabilities.
TAA_NO - TSX Asynchronous Abort (TAA) Avoidance Mitigation
TAA_NO is a readonly extension that is only enabled if the CPU is
not vulnerable to the TSX Asynchronous Abort (TAA) vulnerability
(CVE-2019-11135).
Note -
Only some Intel CPUs are vulnerable to the TAA vulnerability. On
those CPUs TAA may be mitigated by a couple of different methods.
TSX can be disabled automatically by the kernel via an available
control register if available. See the TSX_DISABLE extension be‐
low for more information. If the extensions TAA_NO and TSX_DIS‐
ABLE have a status of not supported, and MDS_NO also has a status
of not supported, TAA may be mitigated by enabling the MD_CLEAR
extension and rebooting. If MDS_NO has a status of enabled, then
if both TAA_NO and TSX_DISABLE have a status of not supported,
TAA can not be mitigated and a microcode update is necessary be‐
fore TAA can be mitigated.
TSA - Transient Scheduler Attacks Mitigation
TSA is a mitigation for the Transient Scheduler Attacks (TSA) se‐
ries of vulnerabilities for AMD CPUs only. The vulnerabilities are
CVE-2024-36348, CVE-2024-36349, CVE-2024-36350, and CVE-2024-36357.
This mitigation will clear the microarchitectural data structures
necessary to mitigate the TSA vulnerabilities in the Level 1 data
cache and store queue on affected CPUs.
Note -
On AMD CPUs that have the TSA_L1_NO and TSA_SQ_NO mitigations en‐
abled, the TSA extension will always be enabled as a readonly ex‐
tension.
This mitigation is enabled by default on systems where it is re‐
quired and supported.
A reboot is required after enabling or disabling TSA for the
changes to take effect.
TSA_L1_NO - Transient Scheduler Attacks L1 Data Cache Mitigation
TSA_L1_NO is a readonly extension that is only enabled if the CPU
is not vulnerable to the Transient Scheduler Attack (TSA) series of
vulnerabilities in the CPU's Level 1 data cache that are mitigated
in software by the TSA extension.
TSA_SQ_NO - Transient Scheduler Attacks Store Queue Mitigation
TSA_SQ_NO is a readonly extension that is only enabled if the CPU
is not vulnerable to the Transient Scheduler Attack (TSA) series of
vulnerabilities in the CPU's store queue that are mitigated in
software by the TSA extension.
TSX_DISABLE - TSX Asynchronous Abort (TAA) Avoidance Mitigation by dis‐
abling TSX
TSX_DISABLE is a readonly extension only for Intel CPUs that is
only enabled if the kernel has a control register available to dis‐
able TSX and TSX has been disabled by this control register.
UMIP - User-Mode Instruction Prevention
UMIP is a mechanism on x86 CPUs that restricts the execution of
specific instructions if the CPU is running outside of its highest
privileged mode (e.g. running in user mode). This is a security
feature to prevent potential manipulation of system software data
structures by malicious userland applications. It is enabled by de‐
fault when it is supported by the hardware.
A reboot is required after enabling or disabling UMIP for the
changes to take effect.
By default, the global zone and all non-global zones have the ASLR, NX‐
HEAP, ADIHEAP, ADISTACK, and SSBD extensions enabled only for tagged
binaries, while the NXSTACK extension is enabled for all processes.
SECURITY EXTENSION PROPERTIES
A security extension can have one or more properties. All extensions
have a model property. This property defines what the extension is ap‐
plied to. Following are the model properties that exist.
model=all
Enable the security extension for all processes.
model=tagged-files
Enable the security extension for tagged binaries.
model=default
Follow the security extension system default. See SECURITY EXTEN‐
SIONS.
Security extensions may have additional properties.
NXHEAP and NXSTACK provide a logging property, which when enabled, re‐
ports attempts to execute from non-executable memory ranges (stack for
NXSTACK, heap and data for NXHEAP).
log=enable
Enable logging.
log=disable
Disable logging. (Default configuration)
MANAGING SECURITY EXTENSIONS
Security extensions can be modified system wide using the sxadm subcom‐
mands enable, disable, set, and delcust. For example, the following sx‐
adm commands enable extensions system wide.
# sxadm enable nxstack
# sxadm enable aslr,nxheap
The following sxadm command also enables extensions system wide by
specifically identifying each property.
# sxadm enable -c model=all aslr
# sxadm enable -c model=all -c log=enable nxstack
Security extensions can also be enabled or disabled for a process using
the sxadm subcommand exec. This subcommand only affects the status of
the security extension. Any other properties of the extension are in‐
herited from the system properties. The following sxadm command ensures
the foobar process executes with disabled extensions.
$ sxadm exec -s aslr=disable -s nxheap=disable foobar
Security extensions can also be configured system wide using smf(7).
The security extensions service is system/security/security-extensions,
and properties are named in the form '[extension]/[property]' where ex‐
tension is the name of the security extension and property is the name
of the property you wish to access.
The extension status can be configured through the '[extension]/config'
property, which may have the following values:
enable: the extension is enabled at boot
disable: the extension is disabled at boot
default: the extension has the Oracle provided default setting
All extensions in Oracle Solaris are shipped with configuration=de‐
fault.
EXECUTABLE TAGGED EXTENSIONS
Individual executables can be tagged with security extension require‐
ments when built with the following ld(1) options.
-z sx=adiheap[=mode]
Control ADI heap allocator usage tagging.
-z sx=adistack[=mode]
Control ADI stack protection tagging.
-z sx=aslr[=mode]
Control ASLR tagging.
-z sx=nxheap[=mode]
Control non-executable heap tagging.
-z sx=nxstack[=mode]
Control non-executable stack tagging.
-z sx=ssbd[=mode]
Control SSBD mitigation tagging.
The mode can be enable or disable. If the mode is not supplied, then
enabled is the default.
The security extension defined within a tagged executable interacts
with any system wide security settings in the following manner.
o Security settings within tagged executables that disable a
specific extension are honored without consulting the system
security settings.
o Security settings within tagged executables that enable a
specific extension are honored only when the system security
setting is tagged-files.
o Security settings specified via sxadm exec override tagged
executable settings.
To determine the tags for an individual executable use elfdump to dis‐
play the dynamic section, and look for tags starting with SUNW_SX_, for
example:
$ elfdump -d /usr/bin/ssh | grep SUNW_SX_
[52] SUNW_SX_ASLR 0x2 ENABLE
[53] SUNW_SX_NXHEAP 0x2 ENABLE
[54] SUNW_SX_NXSTACK 0x2 ENABLE
SUB-COMMANDS
The sxadm command has the following subcommands.
sxadm enable [-c property=value[,property=value,...]] extension[,exten‐
sion,...]
Enable the specified extension for the current zone. The -c option
allows sxadm to pass property values for the specific extension.
If the extension is not configurable, the command fails. If the
change requires a reboot, the extension status is not modified and
the extension is marked as pending changes upon reboot in the FLAGS
output.
sxadm exec [-i] [-s extension=value],... command
Execute the specified command with a specific configuration for se‐
curity extensions. For each security extension not explicitly con‐
figured on the command line, the system configuration is used. A
child process spawned by command does not inherit the security ex‐
tension configuration that is specified on the command line. Inher‐
itance can be enabled using the -i option. setuid and privileged
binaries do not inherit any configuration. Multiple configurations
can be expressed from the command line using multiple -s options.
If the same extension is configured more than once, the last occur‐
rence takes precedence. In the following example, foobar is exe‐
cuted with ASLR enabled.
$ sxadm exec -s aslr=disable -s aslr=enable foobar
The sxadm exec subcommand is designed to accommodate the common
case in which a debugger is applied to a single process started di‐
rectly by the debugger. It may not be sufficient for more complex
scenarios. In such cases, it may be necessary to use sxadm to
change the system or zone level security extension defaults, or to
apply per-object tagging using ld(1), in order to facilitate debug‐
ging.
This feature is primarily of interest when extensions based on a
randomized secret are active (for example, ASLR), since changing
memory addresses can complicate some debugging scenarios. This fea‐
ture is also useful for explicitly testing applications with dif‐
ferent security extension configurations.
sxadm delcust [extension,...]
Restore the extension to the default configuration. This option ef‐
fectively deletes any customizations.
sxadm disable extension[,extension,...]
Disable the specified extension for the current zone.
sxadm help [subcommand]
Display usage information about sxadm or more detailed information
for each subcommand.
sxadm status [-p -o field[,...]] [extension]
Report information on the status of all security extensions for the
current zone. If the -p option is specified, the output is dis‐
played in a format that can be easily parsed. Specifying an exten‐
sion on the command line filters for the specific extension.
Machine parseable output is a list of colon-separated fields.
extension:status[.model]:configuration[.model]:flag[[.flag]...]
where:
extension The name of the extension
status The current status for the extension (enabled or
disabled)
model The current model enabled for the security exten‐
sion (all, default, tagged-binaries)
configuration The stored configuration for the extension (en‐
abled, disabled, or system default)
flag Flags describing the extension. Each flag is sepa‐
rated by a "." within the flags field.
Extensions FLAGS are as follows:
u: userland security extension
k: kernel security extension
c: the extension is configurable
r: configuration changes require a reboot
p: the extension has pending configuration changes which will be
activated upon reboot
The characters colon (:), null sign (\0), and newline (\n) are not
permitted for any of the components.
sxadm get [-p -o field[,...]] property[,...] [extension]
Display the value of security extensions properties. The property
can be defined as the token "all", to display all properties. If
extension is specified, display the value of the property only for
the specified extension. For each property, the following columns
are displayed:
extension: the extension the property refers to
name: the name of the property
value: the value of the property
All columns are displayed by default; specify specific or all
columns, using the -o option. If the -p option is specified, the
output is displayed in an easily parseable format. Such format is a
list of colon-separated fields.
extension:name:value
The characters colon (:), null sign (\0), and newline (\n) are not
permitted for any of the components.
sxadm set property=value[,property=value,...] extension
Assign value to the property of the specified extension.
EXAMPLES
Example 1 Displaying the current Security Extensions Configuration
$ sxadm status -p -o extension,status
aslr:enabled.tagged-files:u.c
nxstack:enabled.all):u.c
[...]
$
$ sxadm status
EXTENSION STATUS FLAGS
aslr enabled (tagged-files) u-c---
nxstack enabled (all) u-c---
[...]
$
Example 2 Use set/get to set/retrieve Security Extensions Properties
$ sxadm get model aslr
EXTENSION PROPERTY VALUE
aslr model default
# sxadm set log=enable nxheap
# sxadm get log nxheap
EXTENSION PROPERTY VALUE
nxheap log enable
Example 3 Running a Debugging Session
The following command sequence illustrates a debugging session being
conducted with ASLR disabled.
$ sxadm exec -i -s aslr=disable /bin/bash
# Because all processes (except privileged ones) inherit the
# (disabled) ASLR configuration, commands such as mdb and truss
# have repeatable results.
$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]
$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]
$ truss -t mmap /bin/true
mmap(0x00000000, 32, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5B0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE5A0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFE590000
[...]
EXIT STATUS
0 The command completed successfully.
1 The command exited due to an error.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/core-os _ Interface StabilityCommit‐
ted
SEE ALSO
elfdump(1), ld(1), exec(2), sx_enabled(3C), adi(7), attributes(7)
Oracle ILOM Administrator's Guide for Configuration and Maintenance
Firmware Release 4.0.x
Fujitsu XSCF Reference Manual
HISTORY
The sxadm command was added in Oracle Solaris 11.1.0.
Support for the following security extensions was first added in the
listed Oracle Solaris release:
tab() box; cw(4.71i) |cw(0.79i) lw(4.71i) |lw(0.79i) EXTENSIONRELEASE _
TSA, TSA_L1_NO, TSA_SQ_NO11.4.87 _ RFDS_CLEAR, RFDS_NO11.4.84 _ SBPB,
SRSO_NO, SRSO_USER_KERNEL_NO11.4.78 _ GDS, GDS_NO11.4.68 _ BTC_NO, SMEP
(see below)11.4.63 _ T{ FB_CLEAR, FBSDP_NO, PSDP_NO, SBDR_SSDP_NO
T}11.4.57 _ UMIP11.4.30 _ TAA_NO, TSX_DISABLE11.4.25 _
IF_PSCHANGE_MC_NO11.4.21 _ RSBS11.4.18 _ MD_CLEAR, MDS_NO11.4.15 _
RDCL_NO11.4.9 _ SSBD (SPARC - see below)11.4.5 _ L1DF, SSBD (x86)11.4.3
_ T{ ADIHEAP, ADISTACK, HW_BTI, IBPB, IBRS, KADI, KPTI, SMAP T}11.4.0 _
NXHEAP, NXSTACK11.3.0 _ ASLR11.1.0
The SSBD extension for SPARC systems was originally delivered in Oracle
Solaris 11.4.5 under the name HW_SSB, and was then renamed to SSBD in
11.4.18.
The SMEP security feature was originally delivered in Oracle Solaris
11.1 for supported Intel CPUs but its status was not reported by sxadm
until Oracle Solaris 11.4.63.
The security extensions IBPB, IBRS, SMAP, SMEP and UMIP that were pre‐
viously only available for Intel CPUs are also available for supported
AMD CPUs as of Oracle Solaris 11.4.60.
Oracle Solaris 11.4 14 Jul 2025 sxadm(8)