Solaris Verified Boot

Solaris Verified Boot Introduction

Verified Boot picture Verified Boot here refers to verification of object modules before execution using digital signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module.


Solaris protects against the loading of rogue kernel modules. Verified Boot increases the security and robustness of Solaris by verifying kernel modules before execution. Examples of these kinds of threats include:

  • Corrupted (accidently modified) kernel modules
  • Insertion or substitution of malicious programs masquerading as legitimate kernel modules (Trojans, viruses, spy-ware, root-kits). These malicious programs can relay information to a third-party or alter the behavior of Solaris
  • Installation of unauthorized third-party kernel modules. Although usually non-malicious, they may be unauthorized and not vetted for security threats or violate site change control policies

Verified Boot Functionality

Verified Boot, before and after
Before Verified Boot After Verified Boot

(Disclaimer: this result has not yet been verified by an
independent lab.)
Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC “bootblk” sectors and initial "unix" module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) "genunix" module and all subsequent modules loaded by the Solaris kernel.

The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled).

  • None is the default behavior—no verification before execution.
  • Warning logs failures to the console and system log. The module is loaded and executed, however.
  • Enforce logs and does not load the module (the module fails to load).

Solaris 11.2: two policy values

For Solaris 11.2 Verified Boot has two policies, boot_policy and module_policy:

  • boot_policy is used in early boot and controls checking of the bootblk and initial "unix" and "genunix" modules.
  • module_policy is used after module genunix is loaded controls checking of subsequent kernel modules (such as from modload(1M)).

Solaris 11.3: one policy: boot_policy

Starting in Solaris 11.3, Verified Boot has just one policy value: boot_policy. SPARC Firmware 9.5.0 and above supports this with only one policy setting (boot_policy). The boot_policy value now controls checking of everything—the bootblk, and the loading of all kernel modules, including "unix" and "genunix". The module_policy value is ignored. In order to best transition from Solaris 11.2 and older SPARC Firmware, the boot_policy and module policy value should always be the same.

The policy settings are stored in the Service Processor (SP), such as Oracle ILOM or Fujitsu M10 XSCF, which manages the hardware platform. The policy settings are purposely stored outside of the booted Solaris environment because we don't trust Solaris (including root or Administrator) to not tamper with these settings.

Chain of Trust

Solaris Verified Boot operates in a "chain of trust" fashion. An verified software is not used to verify other code or even itself until it's verified. Only after verification may software verify other software. Consider this simple diagram showing Solaris boot flow:

OpenBoot bootblock /platform/.../unix genunix . . . sha2

The chain of trust starts with OpenBoot firmware. The firmware is factory-installed or customer-installed from factory-signed packages. OpenBoot verifies the SPARC boot block (bootblk) sectors and the initial Solaris /platform/.../unix module and starts execution in the bootblk. Bootblk executes the initial Solaris module, unix. From there, the Solaris kernel loader, part of module unix, takes over. Krtld verifies genunix (Generic UNIX) and loads it and verifies all subsequent kernel modules. SHA-256 functionality, required to verify kernel modules, is contained in a yet-to-be-loaded module, sha2. Until sha2 is loaded, Solaris uses temporary, unoptimized "standalone" code to calculate SHA-256 digests as part of verifying the RSA-2048 signature.

Solaris Security Ecosystem

Solaris Verified Boot is not a standalone Security solution independent of everything else. By interacting with other Solaris security solutions, it makes for a more robust, secure environment:

  • Solaris SPARC firmware is signed using DSA-2048. Only signed firmware can be installed on SPARC platforms.
  • Secure Auto-Install (AI) and signed IPS packages (pkgsign(1)) help ensure the software you're installing is legitimate and has not been corrupted.
  • Immutable Zones implements a read-only root filesystem to make a zone tamper-resistant.
  • Packaging Solaris packages are factory-signed at Oracle. Third-party packages may be signed by the software vendor.
  • Boot Environments Multiple Boot Environments (BEs) allow one of several instances of Solaris to be booted. When the platform is configured with BEs, switching between BEs does not allow one to bypass the Verified Boot policy. If the system is configured to perform a fully-verified boot ("enforce"), but the BE being booted contains unsigned or corrupt kernel modules, the system administrator may need to loosen the boot policy (set it to "warning").
  • TPM Solaris Verified Boot has no impact on the Trusted Platform Module (TPM) chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles.

Together, these security solutions provide an end-to-end solution to help secure against tampering, from firmware to operating system software.

Elfsign Keys

Elf signing Solaris executable object, including kernel modules, are factory-signed with elfsign(1) by Oracle Solaris Release Engineering with a RSA-2048 public/private key pair. The private key is not distributed by Oracle. The public key is distributed in /etc/certs/ORCLS11SE.

The current public key cert for Solaris 11 Updates is in /etc/certs/ORCLS11SE. This code signing cert is issued by Verisign to Oracle and object is signed and verified with the elfsign(1) command.

Solaris Verified Boot cannot trust Solaris to store the keys in the filesystem (as a key in /etc/certs/ can be modified or a key can be added by any privileged user), so the key must be stored outside in the pre-boot environment. For SPARC, this is the SP. For Sun SPARC T5/M5/M6 this is Oracle ILOM. For Fujitsu M10, this is the XSCF.

The elfsign public key certificate is represented as a X.509 text file. For Solaris 11 Update, elfsign uses rsa_sha1 (rsa-2048 of sha1). Other elfsign public keys may be present for:

  • Third-party software modules (usually for hardware drivers). These can be signed with a code-signing certificate issued by Verisign or some other CA, or can be signed with a self-issued certificate.
  • Customer-signed software modules (including self-issued certificates) to sign unsigned third-party modules (that is, software not signed by the software author). This includes compiled open source modules and hardware-specific modules.
  • Oracle (factory) signed software. All Solaris kernel modules are signed with elfsign before release to customers. For external Solaris 11 (or S11 update), this can be verified with "elfsign verify" using the public key cert in file /etc/certs/ORCLS11SE. The following command displays the contents of a X.509 certificate file:
    openssl x509 -noout -text -in /etc/certs/ORCLS11SE

For more information on elfsign see my earlier article "Elfsign Object Signing on Solaris".

Setting Verified Boot Policy Values in Oracle ILOM

Verified Boot settings are maintained by Oracle ILOM. They can be modified or viewed by the ILOM UI, spsh, or the BUI (web) interface. From the ILOM UI, you can configure and display policy settings, pre-installed system certificates, and custom (user-provided) certificates. For this purpose the verified_boot target is /HOSTx/verified_boot (where "HOSTx" is "HOST" for T5 systems and other systems with only one physical domain , or HOST0, HOST1, HOST2, ... for systems with multiple physical domains). Changes in the policy settings or certificates in Oracle ILOM are not available to the Solaris host immediately, but are not used until the next reboot of the guest to OpenBoot (a complete host reboot/shutdown is not needed).

ILOM provides boot_policy and module_policy properties to set Verified Boot policies. The following example sets boot_policy to enforce and module_policy to warning:

-> set /HOST1/verified_boot/ boot_policy=warning
Set 'boot_policy' to 'warning'

-> set /HOST1/verified_boot/ module_policy=enforce
Set 'module_policy' to 'enforce'

-> show /HOST1/verified_boot/


        boot_policy = warning
        module_policy = enforce


ILOM Certificate Management

If you only use Oracle Solaris kernel modules and drivers, no certificate management is necessary. That's because the Oracle Solaris certificate used by elfsign, /etc/certs/ORCLS11SE, is built-in ILOM and Solaris Verified Boot. However, if you use third-party modules or drivers, you need to add the public key X.509 certificate (cert). This is not needed for third-party libraries and executible files as Verified Boot only checks Solaris kernel modules. The certificate may be issued by a Certificate Authority (CA) or be self-signed. The chain of trust is established by installing the cert in ILOM.

ILOM allows adding and viewing of both system-provided or "built-in" certs (target system_certs) and user provided certs (target user_certs). Initially under /HOSTx/verified_boot/system_certs is a single target, /HOSTx/verified_boot/system_certs/1, that corresponds to the pre-installed certificate file for Solaris. Updates to ILOM may add more numerically identified system certificate files to support newer versions of Solaris. The system-provided cert is represented by the ILOM target /HOSTx/verified_boot/system_certs/1. Pre-installed certificates for future OS releases will populate target /HOSTx/verified_boot/system_certs/2 and beyond. User-installed certificates are preserved across firmware updates. Valid certificate files are plain ASCII text in X.509 format.

The following example displays the system-provided cert:

-> show /HOST1/verified_boot/system_certs/1


        issuer = /C=US/O=Oracle Corporation/OU=VeriSign Trust Network/OU=Class 
                 2 Managed PKI Individual Subscriber CA/CN=Object Signing CA
        subject = /O=Oracle Corporation/OU=Corporate Object Signing/OU=Solaris 
                  Signed Execution/CN=Solaris 11
        valid_from = Mar  1 00:00:00 2012 GMT
        valid_until = Mar  1 23:59:59 2015 GMT

ILOM User-managed Certificates

The /HOSTx/verified_boot/user_certs/{ID} UI supports load and reset of up to 5 custom certificate files for each domain:

  • The load command loads the certificate from the user-provided URL.
  • The reset command removes removes the specified user certificate.
  • The show command displays a certificate.

Below are examples for show, load, and reset of the certificate file:

-> set /HOST1/verified_boot/user_certs/1 load_uri=
Load successful.

-> show /HOST1/verified_boot/user_certs/3


        clear_action = (Cannot show property)
        issuer = /O=Dog Wash Software/OU=Release
        load_uri = (Cannot show property)
        subject = /O=Dog Wash Software/OU=Release 
        valid_from = Oct  4 21:08:00 2013 GMT
        valid_until = Sep 27 21:08:00 2023 GMT

-> reset /HOST1/verified_boot/user_certs/2
Are you sure you want to reset /HOST1/verified_boot/user_certs/2 (y/n)? y
Performing reset on /HOST1/verified_boot/user_certs/2

-> show /HOST1/verified_boot/user_certs/2 issuer

        clear_action = (Cannot show property)
        issuer = (none)         <--- not installed
        load_uri = (Cannot show property)
        subject = (none)
        valid_from = (none)
        valid_until = (none)


Here's an example of loading a certificate by pasting the contents into the ILOM console. Terminate the console input with a ctrl-z.

-> set /HOST1/verified_boot/user_certs/1 load_uri=console
Begin cut-and-paste below.
Enter [ctrl-z] to save and process information.
Enter [ctrl-c] to exit and discard changes
Load successful. 

ILOM Web Interface

The web interface also supports setting of the Verified Boot policy variables and and management of Certificate files, providing the same functionality as the CLI. Just navigate to the "Verified Boot" link under the "Host Management" navigation menu. Here's a screenshot (click on it to enlarge):

ILOM web interface screenshot

ILOM Security Considerations

The Sun SPARC T5/M5/M6 pre-boot environment stores Verified Boot settings in ILOM. Anyone with ILOM spsh shell access can modify these settings. One can reach the ILOM shell with ssh to the ILOM console. If the password can be easily guessed, these settings can be modified. ILOM console access should be isolated to a separate management network that's separate from the general network with restricted access to ILOM administrators. If feasible, ILOM access can be restricted to the ILOM serial port with no network access.

In order to use Verified Boot, the "use-nvram" setting must be set to false in OpenBoot. This prevents OpenBoot from being modified to disable Verified Boot functionality. The default value is false and can be viewed in Solaris by typing:

$ /usr/sbin/eeprom/eeprom use-nvramrc?

If set to true it can be modified in OpenBoot. For example,

{900} ok printenv use-nvramrc?
use-nvramrc? =          true
{900} ok setenv use-nvramrc? false
use-nvramrc? =          false
{900} ok printenv use-nvramrc?
use-nvramrc? =          false  


Verified Boot verifies the elfsign signature contained in a kernel module. These signatures have been present since Solaris 10. For Solaris 11.2 the signature format is a RSA-2048 signature of a SHA-256 or SHA-1 digest.

To verify, the Solaris krtld loader extracts the signature from the kernel module and calculates the ELF file digest (which excludes the signature, among other things). The expected digest is calculated from the signature and public key as follows: signature65537 % public-key.

If the expected digest (excluding PKCS#1 padding) matches the actual digest just calculated, the signature is OK. This process is repeated for every cert until a match is found. Here's a diagram of the process:

Verified Boot signature verification


Verified Boot has little performance impact. That's because loading kernel modules are mostly I/O bound, most systems only load ~200-300 modules during boot, and the additional time for signature verification is negligible. The overall boot time increases by ~2.5 seconds on a T5.


Solaris Verified Boot is available with Solaris 11.2 for Sun SPARC T5/M5/M6 hardware platforms for host domains (with Sun Firmware FW 9.1.0 or better) and Fujitsu M10 systems (with Firmware XCP2250 firmware). Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules.

Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware and software platforms in the future, but there is no commitment to do so.

More Information

Here's some sources for further information. Most of these documents are available at

(Updated 7/2015 to add information about Fujitsu M10 support and add link to Verified Boot for Kernel Zones.)
(Updated 11/2015 to document Solaris 11.3 has only one policy setting, boot_policy.)


Post a Comment:
  • HTML Syntax: NOT allowed

Solaris cryptography and optimization.


« November 2015