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.
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 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.
-
Both control modules start their boot sequence. During this sequence, the
following occurs:
- The BIOS tries to boot off the internal storage device.
- 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.
- When the initramfs has loaded, the application manager (app_mgr) starts and loads the applications based on their start order.
- The system is operational.
- 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.
- 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, and some signatures are based on SHA-256 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.
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> detailCheck 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
up-to-date status
: Status of the Secure Boot variables programmed in the control module compared to the current modification datasetupdate-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.
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.
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
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>
TPM Keys (IDevID and IAK)
The control cards (CPMs) are provisioned by Nokia at manufacturing time with two identity keys and their associated x509 certificates signed by the Nokia Factory Certificate Authority (CA).
Initial Device Identity (IDevID)
The factory-provisioned Initial Device Identity (IDevID) is a private key, and its associate certificate is signed by Nokia IP Routing Factory CA. This identity key and certificate are then used in software features to provide cryptographic evidence that the system used by the customer was manufactured by Nokia. The provisioning of the keys and certificates follows the Trusted Computing Group (TCG) TPM 2.0 Keys for Device Identity and Attestation specifications. The IDevID certificate binds the TPM to its control card by including the serial number of the control card in the certificate subject field. The IDevID can be used in secure remote bootstraps to authenticate the SR Linux router as a client, it can also be used in the TLS server profile to authenticate the router acting as a server.
Initial Attestation Key (IAK)
The factory-provisioned Initial Attestation Key (IAK) is a private key, and its associate certificate is signed by Nokia IP Routing Factory CA. Similar to IDevID, the IAK certificate contains the control card serial number, binding the TPM to the control card. The provisioning of the keys and certificates follows the Trusted Computing Group (TCG) TPM 2.0 Keys for Device Identity and Attestation specifications. The IAK is a TPM restricted signing key used to sign TPM quotes, thereby providing cryptographic evidence that the information produced by the TPM originated from a genuine discrete TPM and the expected system.Viewing TPM certificates
Viewing an IAK certificate on TPM
The command below shows an example of an IAK certificate that has been installed on the TPM.
# show platform trust tpm control B certificate initial-attestation-key
Certificate initial-attestation-key :
NV Index : 0x1c91000
Subject : CN=3HE17011AB-NS224662905-IAK,O=Nokia,serialNumber=NS224662905
Issuer : CN=Nokia PoC RSA Issuing,O=Nokia,street=600 Mountain Ave\, Ste 700,postalCode=07974,L=Murray Hill,ST=NJ,C=US
Fingerprint : 60:33:76:88:D6:E5:C3:30:8D:C1:47:6E:4C:F6:70:28:0F:C2:73:D5:C0:82:98
:2A:1C:AE:95:6F:B8:10:CF:C6
Measured Boot
SR Linux control cards (CPMs) TPM 2.0 is the hardware root of trust for measurement and attestation in the context of Measure Boot. Measured Boot complements Secure Boot by providing cryptographic evidence that each piece of the system boot chain uses the software version allowed by the operator.
In a Measured Boot chain, each step in the boot process measures the next element before executing it. The initial boot firmware makes the first measurement in this boot chain and is the root of trust for measurements. Each measurement is a cryptographic hash value, and it is stored (extended) in the TPM Platform Configuration Register (PCR).
A measurement is extended in the TPM PCR instead of being directly written into it. The TPM performs this function by concatenating the previous hash value of the PCR with the new measurement. As a result, it is not possible to undo a measurement by design.
The boot process is described in the diagram below:
![](graphics/measured_boot_process.png)
After the router has established network connectivity, the operator can verify the integrity of the boot measurements as described in the remote attestation section.
Viewing TPM PCR allocation
SR
Linux is TPM 2.0 compliant and uses the tpm20-hash-algo
cryptographic algorithm to hash the PCR measurements. An allocation refers to a list
of banks and selected PCRs.
In the following example SHA1 and SHA256 banks with PCRs 0 - 23 are allocated.
--{ candidate shared default }--[ ]--
# show platform trust tpm control A pcr-bank
+----------------+--------------------------------------------------------------------------------------+
| Hash Algorithm | PCR Allocation |
+================+======================================================================================+
| sha1 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 |
| sha256 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 |
+----------------+--------------------------------------------------------------------------------------+
PCR measurements
The SR Linux boot process and PCR usage are compliant with the Trusting Computing Group specifications, which include TPM/PCR initialization and Event Logs.
The boot phase events up to kernel run-time are recorded in the attestation BIOS log, as defined by the TCG.
At run-time, the Linux kernel Integrity Measurement Architecture (IMA) also records in PCR10 the measurements for anything executed or read by the root. The associated events are logged in the IMA log.
PCR | Description |
---|---|
0 | BIOS |
2 | UEFI driver/application Code |
4 | Boot Manager Code: SHIM, GRUB, kernel |
6 | Host Platform Manufacturer Specific |
9 | GRUB read/executed files: kernel, initramfs |
14 | Root File System: SquashFS |
Displaying PCR values
Operators can view TPM PCR measurements in the appropriate PCR registers using the
command tools platform trust attestation control <A|B> pcr-read
pcr-selection <value>
, and compare them to the reference values,
confirming the validity of the entire platform boot chain from firmware to SR Linux
application launch. For information about reference values, see Reference values.
# tools platform trust attestation control A pcr-read pcr-selection "sha256:0,1,2,3,4,5,6,7,8,9,10"
TPM PCR Read results for sha256:0,1,2,3,4,5,6,7,8,9,10
sha256:
0 : 0x43B4FD809823280E8A7D7A31C7D278CBD4A9994A13258A3D0E42C1940CC14222
1 : 0x8E341EA8C2E1150C53613FB442340939B4BA54425309BFE4E9D71F7F44769753
2 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
3 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
4 : 0x0D05C6F050C5CD50543438ACCE37868056D932DA0EF2D3624905CAE432E8231D
5 : 0x8BEB965936843F26EDAC516D370F543AE1CB38506700160A25937AF1FCC8BE50
6 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
7 : 0x65CAF8DD1E0EA7A6347B635D2B379C93B9A1351EDC2AFC3ECDA700E534EB3068
8 : 0xFAAB584987876D99A3D55E9ADDFFF6897C921F3759CE6DE020AC67E5EAAB351A
9 : 0xC0885BD8B03BF30092AEACDE3ECCFCE88815EA2017B39C838BAD977BBD4F585A
10 : 0x7D2F7D1077AD760E9CA75DB079CB5AEBDBA807378F120DF96FA531CFA56CBC6D
Retrieving BIOS and IMA event logs
To ensure trust in each recorded event, an operator can re-compute the event log for a specific PCR and compare it with the running system PCR value. This is useful for identifying which event is causing a discrepancy when the final PCR value is not as expected .
Retrieving BIOS event logs
In the following example, BIOS event logs are retrieved from PCR 0.# tools platform trust attestation control B log-retrieval bios display from 1 to 2
Event: 1
PCRIndex: 0
EventType: 0x8 (EV_S_CRTM_VERSION)
Digest Count - 2
Hash Algo - 4 (sha1)
Digest - 1489f923c4dca729178b3e3233458550d8dddf29
Hash Algo - 11 (sha256)
Digest - 96a296d224f285c67bee93c30f8a309157f0daa35dc5b87e410b78630a09cfc7
Event Data (base64): AAA=
Decode:
===============
Event: 2
PCRIndex: 0
EventType: 0x80000008 (EV_EFI_PLATFORM_FIRMWARE_BLOB)
Digest Count - 2
Hash Algo - 4 (sha1)
Digest - 07459f28fdd346be4c9f179aae26998e82384625
Hash Algo - 11 (sha256)
Digest - 6e460fa66a9abece4ea81a5267616fb00cd9ddf1b59a8d120a0b6695ec00c883
Event Data (base64): AADo/wAAAAAAABgAAAAAAA==
Retrieving IMA event logs
Linux IMA does not have a known good final PCR value because the system constantly records new measurements into the IMA PCR.
In the following example, IMA event logs are retrieved from PCR 10.# tools platform trust attestation control B log-retrieval ima display from 1 to 1
Event: 1
PCR: 10
Template Name: ima-ng
Digest type: sha256
Digest: 582f3a3b53db66797618d4d9de3891e8e34a1903cb262b545e20affe4fe8b432
Event Name: boot_aggregate
Reference values
Verifiers can assess the system health by comparing TPM PCR measurements to published reference values. The PCR reference value file (known_good_pcr_values.json) is bundled in the SR Linux software distribution for each release and is present in the /mnt/nokiaos/<build binary.bin>/ directory.
Remote Attestation / Integrity Verification
For remote attestation and integrity verification, a separate Verifier, operating in its secure environment, interrogates the network device to retrieve a quote of the PCRs relevant to the attestation operation, and optionally, the Boot event log.
A quote created by the TPM is a TCG (Trusted Computing Group) defined structure that contains a digest of the PCRs selected and signed by the Initial Attestation Key (IAK) to provide evidence that it originated from the expected Nokia system.
Retrieving TPM PCR quotes
SR Linux follows the challenge-response interaction model. The Verifier includes the
nonce
and pcr-selection
parameters in its TPM
quote request. A nonce
is
a
base64 randomly generated number intended to guarantee freshness and is used as part
of a
replay-protection
mechanism.
The pcr-selection
is a tpm2-tools
compliant
string,
it indicates the bank selection and the list of PCRs.
In this example, a PCR quote is generated by using nonce
value
"AQIDBAU=" and the PCR measurement values from PCRs 0, 1,
4, and 9 of SHA256 bank.
# tools platform trust attestation control A pcr-quote pcr-selection sha256:0,1,4,9 nonce AQIDBAU=
Quote Message
/1RDR4AYACIAC4FZZKr0a3ASLDLbqwprA0/JqMST9CyW6qzJLpdNBb5aAAUBAgMEBQAAAAAfnxrfAAAA0QAAAAABAEoAQESgGgMAAAABAAsDEwIAACAumDsE26qFifhCyLSD8BzWITTQ9VDPqyOstckkzocIJQ==
Quote Message Signature
ABQACwEACwKaKaIwRS89vjAxR0jYs94XeNoFPHDUMsbtCZFyxr6DhezIQDyNsi3t5p/XEZyGK9PuFOTXh7LoiiNsgBbxpXOxnbnFoB/iUv2yKg1xMd0zfbCpQXKSbtpWIevCwXsNonV/QTR8MhlX9CDAXF8Ij1okbKylQwwQrdm+4EACHM+sWTuO0DuT6ncKU0tAujtcQEDpeABTiSNhZE81Fg4tPNaj5zAE1cs6QX1fqWB6TNtEuCeUM8SH9wQbOKWXkwZDZDXZ9ssQ+XurO35DT3uS9xg3DJqd8t99yyh6jTO7nx/euV7hDr+KbBNVKCX0gsRCiIRBjqdyxbVu++iK3wZBFg==
Quoted PCRs
AQAAAAsAAxMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAQAAAAQAAAAgAHh9RiQh7oJcUXXmYgBIutUzjeCKHoRvei9wF9zz/UmZAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAgADl/pI5hMi+sdRKNNFEZZ7S5klA6EwiSkl2OB1BzhzoAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAgAA0FxvBQxc1QVDQ4rM43hoBW2TLaDvLTYkkFyuQy6CMdAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAJOLh47xcSkxPpxHMgiizHEfaaEv4uFAG1hJ0TdOr76zAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=