SR Linux software overview

This chapter describes the basic software operations on the SR Linux.

File system layout

The file system is distributed and laid out as a closed-source third-party application on the OS. The following table lists the file system layout.

Table 1. File system layout

Path

Description
/opt/srlinux/appmgr/* YAML configuration for Nokia-provided applications
/opt/srlinux/appmgr/aaa_mgr System files for AAA manager
/opt/srlinux/appmgr/logmgr System files for log manager
/opt/srlinux/bin/* Application binaries
/opt/srlinux/firmware/* Contains firmware (BIOS, IOCTL, CPLD, and so on)
/opt/srlinux/imm/imminit.tar IMM image
/opt/srlinux/lib/* Nokia-provided shared libraries
/opt/srlinux/models/* Nokia-provided YANG models
opt/srlinux/config.json Factory system configuration
/opt/srlinux/osync/* Configuration files and exclude/include files for overlay synchronization
/opt/srlinux/python/* The virtual environment used to run SR Linux Python processes
/opt/srlinux/systemd/* Systemd unit files and configuration
/opt/srlinux/usr/* Community-provided binaries, shared libraries, and licenses
/opt/srlinux/var/run/* Running directory for process sockets
/opt/srlinux/ztp/* ZTP virtual environment, templates, and client
/etc/opt/srlinux/config.json System configuration
/etc/opt/srlinux/config.json.gz Compressed system configuration (if the configuration needs to compressed)
/etc/opt/srlinux/banner The system banner, pre-login
/etc/opt/srlinux/license.key License file
/etc/opt/srlinux/srlinux.rc Global environment file
/etc/opt/srlinux/tls/* User-configured certificates
/etc/opt/srlinux/appmgr/* YAML configuration for operator-provided agents
/etc/opt/srlinux/appmgr/overrides YAML overrides for operator and Nokia-provided applications
/etc/opt/srlinux/models/* YANG modules for operator-provided agents
/etc/opt/srlinux/checkpoint/* Configuration checkpoints
/etc/opt/srlinux/devices/* Discovered devices
/etc/opt/srlinux/cli/plugins/* Operator-provided plug-ins
/var/opt/srlinux/run/* Application PIDs
/var/log/srlinux/buffer/* Tmpfs logging
/var/log/srlinux/buffer.persist/* Persistent buffered logging
/var/log/srlinux/file/* Persistent logging
/var/log/srlinux/debug/* Debug logging, tmpfs
/var/log/srlinux/debug.persist/* Persistent debug logging
/var/log/srlinux/monitor/* Log_mgr tmpfs storage
/var/log/srlinux/monitor.persist/* Log_mgr persistent storage
/var/log/srlinux/archive/* Archive directory for previous startups
$HOME/.srlinuxrc Per-user environment
$HOME/srlinux/cli/plugins/* Per-user CLI plug-ins

The Solid State Drive (SSD) is used for an overlay file system, allowing the user to add persistent modifications to the system.

Boot process

The SR Linux boots using a normal Linux boot mechanism. The BIOS is set up to boot from the internal storage device. The following is the normal boot sequence:
  1. The system powers on. Assuming a fully populated system, all components initialize to the point where they bring up their link on the back door bus. Fans are under hardware control and run at 100% speed.
  2. Both control modules start their boot sequence. During this sequence, the following occurs:
    1. The BIOS tries to boot off the internal storage device.
    2. Grub2 loads the kernel and initramfs into memory. The initramfs contains a squashfs of the root file system used to run SR Linux, including base Debian and SR Linux applications. The squashfs is unpacked and loaded.
    3. When the initramfs has loaded, the application manager (app_mgr) starts and loads the applications based on their start order.
    4. The system is operational.
  3. On control-redundant platforms, both control modules attempt to boot at the same time. The control module in slot B waits up to 300 seconds before becoming active, after detecting slot 1 on the back door bus.
  4. The chassis_mgr and device_mgr initialize, push images, and boot each line card and Switch Fabric Module (SFM). This includes making any decisions based on power availability, and taking control of fans.

Secure Boot

SR Linux Secure Boot ensures that the software executed by the system is trusted and originated from Nokia IP routing.

At every boot of the control card, each step in the boot process verifies the digital signature of the next software element to boot for integrity and authenticity up to the SR Linux application contained in the squashfs root file system. This boot sequence forms the chain of trust for Secure Boot.

The Secure Boot chain is rooted in the platform control card firmware based on UEFI (Unified Extensible Firmware Interface Root of Trust) specifications. As such, Nokia Platform Key, Key Exchange Key, allowed and disallowed databases are provisioned in the system when Secure Boot is activated to perform the required signature verification.

Firmware updates are also digitally signed and verified using the same principle. The signature verification of a firmware update is performed at boot time by the existing firmware before the firmware update can proceed.

Software image signatures use RSA-4096 keys and SHA-384 hashes.

Activate Secure Boot

Depending on the system, Secure Boot can be enabled from manufacturing or field enabled on compatible system control cards using CLI commands.

To activate Secure Boot on compatible control cards that do not have Secure Boot enabled from manufacturing, the following command is used providing the card slot, card serial number, and confirmation code:

tools platform trust secure-boot control <A|B> activate confirmation-code <string> serial-number <string>

The card serial number and Secure Boot confirmation code are required to avoid accidental activation of Secure Boot in the network. The confirmation code is secure-boot-permanent.

The Secure Boot activate command verifies that the boot chain used at the next reboot of the system is properly signed otherwise the command returns an error in CLI.

WARNING:

After Secure Boot is activated on a control card, the capability is permanently enabled and cannot be disabled. The control card permanently refuses to execute unsigned software for security reasons. As a result, it is not possible to downgrade to a software release published before the release that introduced Secure Boot for a specific platform.

The following example activates Secure Boot on slot A.

A:srl1# tools platform trust secure-boot control A activate confirmation-code secure-boot-permanent serial-number NS22222222

The following example shows the warning messages and prompt returned when proceeding with Secure Boot activation:

WARNING: This operation will permanently activate secure boot on the card and cannot be reversed. The card will also be immediately rebooted. After activation, the system will only accept digitally signed software and will not boot using un-signed software.
Are you sure you want to activate secure boot and reboot this control module (y/[n])?y

Secure Boot state

Secure Boot status is available per control card and is obtained using the following command:

show platform trust secure-boot control <slot> detail

Check Secure Boot status

The following example checks the Secure Boot on slot A.

A:srl1# show platform trust secure-boot control A
  +------+--------------------+
  | Slot | Operational Status |
  +======+====================+
  | A    | enabled            |
  +------+--------------------+

The Operational Status indicates whether the Secure Boot is enabled or disabled.

Check detailed Secure Boot state information command per control card

The show platform trust secure-boot control <A|B> detail command provides detailed Secure Boot state information based on the currently used Secure Boot UEFI variables and the modification dataset such as:
  • up-to-date status: Status of the Secure Boot variables programmed in the control module compared to the current modification dataset
  • update-required status: Indicates which variable require updating
A:Dut-A# show platform trust secure-boot control A detail
=======================================================================================================================================
  Show report for Secure Boot on Controller A
=======================================================================================================================================
  Summary
    Operational Status: enabled
  Database Variable Modification Dataset Status
    Modification Dataset Present     : true
    Modification Dataset Valid       : true
    Variables Up To Date             : true
    dbx Update Required              : false
    db Update Required               : false
    PK Update Required               : false
    KEK Update Required              : false
    Modification Dataset db Conflict : false
    Modification Dataset dbx Conflict: false
    Modification Dataset Digest      : 0b5e6d97c0915ad9698634b2889da9fc37b3271d0f7914304c58f819ba037f6c
=======================================================================================================================================
  UEFI Security Database Variables

Update Secure Boot variables

In case the Secure Boot UEFI variables are updated, specific secure boot commands are used to update the allowed (db) and disallowed (dbx) databases programmed in the CPM firmware.

To activate or update the Secure Boot, the SR Linux software image contains a modification dataset that includes the UEFI variables, which can be installed on the control cards.

If a change to the UEFI db or dbx is included in a future software release, the operator must install the new UEFI variable modification dataset before deploying the new image. The UEFI variable modification dataset is included in the binary image of the new software, in the current SR Linux file system.

Use the following command to extract and install a secure boot variable update from the specified image file:
tools system secure-boot install-update <file> namespace <value>
where,
  • file: refers to the file path or HTTP/HTTPS/SFTP URL for the image file. Default HTTP/HTTPS URL download mode is insecure.
  • namespace: refers to the network namespace to use when downloading the image.
For example, 
tools system secure-boot install-update srlinux.bin

Use the following command to display the installed update:

tools system secure-boot display-update file <value>
where, file refers to the file path of the secure boot variable update package. For example,
tools system secure-boot display-update file /etc/opt/srlinux/secure_boot_var_update.json
After installing the UEFI variable modification dataset, the operator must update the UEFI databases (db/dbx) programmed in the CPM firmware.
  • To update the UEFI db per control card, use the following command:
    tools platform trust secure-boot control <A|B> update confirmation-code <string> serial-number <string>
  • If a change to the UEFI dbx is included in the currently running software release, the operator must execute the following command per control card:
    tools platform trust secure-boot control <A|B> revoke confirmation-code <string> serial-number <string>