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)
/mnt/nokiaos/<version>/imminit.tar	IMM image
/opt/srlinux/lib/*	Nokia-provided shared libraries
/opt/srlinux/models/*	Nokia-provided YANG models
/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/*	Softlink to the devices directory: /var/run/srlinux/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
/var/run/srlinux/devices/*	Discovered devices
$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 from an internal storage device (SD/SSD)

Note: This boot process applies only to 7250 IXR, 7250 IXR-X1b/X3b, 7220 IXR-D, 7220 IXR-DL, 7220 IXR-H, and 7730 SXR systems.

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:

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:
1. The BIOS tries to boot off the internal storage device.
2. Grub2 loads the kernel and initramfs into memory. The kernel command line points to 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 squashfs root filesystem is loaded, the application manager (sr_app_mgr) starts and loads the applications based on their start order.
4. 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 30 seconds before becoming active, after detecting slot 'A' on the back door bus.
On multi-slot platforms, the sr_chassis_mgr and sr_device_mgr initialize, push images, and boot each line card and Switch Fabric Module (SFM). This includes making decisions based on power availability and taking control of fans.

Boot process from an embedded Multi-Media Card (eMMC)

Note: This boot process applies only to the 7215 IXS system.

The SR Linux boots using a normal Linux boot mechanism. The U-Boot is set up to boot from an eMMC. The following is the normal boot sequence. For starting SR Linux with factory defaults, see Starting SR Linux with factory defaults.

The system powers on. The U-Boot loads the SR Linux Flattened Image Tree (FIT) image from an eMMC storage into memory, which contains the kernel, device tree, and initramfs. The kernel command line points to squashfs of the root file system used to run SR Linux, including base Debian and SR Linux applications. The squashfs is unpacked and loaded.
After the squashfs root filesystem has loaded, the application manager (sr_app_mgr) starts and loads the applications based on their start order.
The sr_device_mgr initializes the PSUs, fans, and LED system devices, upgrades firmware if required, and then the sr_app_mgr sequentially launches the remaining applications.
The system is operational.

Secure Boot

Note:

Secure Boot is supported on 7250 IXR-6e and 7250 IXR-10e CPM4 with Root of Trust, 7250 IXR-X1b/X3b, and 7730 SXR systems.

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) 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 update application 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.

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>
```

TPM Keys (IDevID and IAK)

Note:

TPM keys are supported on 7250 IXR-6e and 7250 IXR-10e CPM4 with Root of Trust, 7250 IXR-X1b/X3b, and 7730 SXR systems.

The control cards (CPMs) are provisioned by Nokia at manufacturing time with identity keys and their associated x509 certificates signed by the Nokia Factory Certificate Authority (CA).

These keys and certificates are permanently programmed in the Trust Platform Module (TPM) of the control card and can be used for device authentication or attestation. The asymmetric cryptographic algorithm for the identity key depends on the platform: RSA-2048 for 7250 IXR CPM4 with RoT, 7250 IXR-X1b/X3b, and ECC P-384 for 7730 SXR.

Initial Device Identity (IDevID)

The factory-provisioned Initial Device Identity (IDevID) is a private key, and its associated 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 bootstrap to authenticate the SR Linux router as a client and 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 associated 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

Each CPM is factory-provisioned with IDevID and IAK keys . The Endorsement Key (EK) is provisioned by the TPM manufacturer. The signing and provisioning of the IDevID/IAK certificate binds the TPM to a CPM unique identifier, the serial number and platform type.

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

Note: Measured Boot is supported on 7250 IXR-6e and 7250 IXR-10e CPM4 with Root of Trust, 7250 IXR-X1b/X3b, and 7730 SXR systems.

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:

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 systems that contain TPM 2.0 compliant TPM devices use one or more of the tpm20-hash-algo cryptographic algorithms to hash the PCR measurements. An allocation refers to a list of banks and selected PCRs. This allocation is static for a given system.

In the following example, the TPM has two PCR banks, with both the SHA1 bank and SHA256 bank containing PCRs 0-23.

--{ 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.

The PCRs relevant to software attestation are:

Table 2. Software attestation PCRs
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.

The following example retrieves the PCR measurement values from PCRs 0 to 10 from SHA256 bank.

# 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 use the event log to re-compute 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.

Note: Reference values only include the final PCR value, not the individual PCR events value.

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 operator 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=