Skip to content

Latest commit

 

History

History
156 lines (110 loc) · 8.95 KB

README.md

File metadata and controls

156 lines (110 loc) · 8.95 KB

Arm Enterprise ACS - Architecture Compliance Suite

Architecture Compliance Suite

Architecture Compliance Suite (ACS) is used to ensure architectural compliance across different implementations of the architecture. Arm Enterprise ACS includes a set of examples of the invariant behaviors that are provided by a set of specifications for enterprise systems (For example: SBSA, SBBR, etc.), so that implementers can verify if these behaviours have been interpreted correctly. ACS is delivered with tests in source form along with a build script, the output of the build being a bootable Linux UEFI Validation (LUV) OS image that can run all tests required by these specifications.

Arm Enterprise ACS tests are available open source. The tests and the corresponding abstraction layers are available with an Apache v2 license allowing for external contribution.

In summary, the Arm Enterprise ACS product contains the following:

    1. Scripts to build, construct, and run the test images.
    2. A bootable LUV OS image capable of running all tests.
    3. Documentation on running the tests.

These tests are split between UEFI and Linux (supported by corresponding kernel driver) applications that together determine whether an architectural implementation is compliant with the enterprise specifications. These tests are further described in detail.

Release details

  • Code Quality: REL v3.0
  • The latest pre-built release of ACS is available for download here: v20.10_REL3.0
  • The SBSA tests are written for version 6.0 of the SBSA specification.
  • The SBBR tests are written for version 1.2 of the SBBR specification.
  • The compliance suite is not a substitute for design verification.
  • To review the ACS logs, Arm licensees can contact Arm directly through their partner managers.

GitHub branch

  • To pick up the release version of the code, checkout the release branch with the appropriate tag.
  • To get the latest version of the code with bug fixes and new features, use the master branch.

ACS build steps

Prebuilt images

  • Prebuilt images for each release are available in the prebuilt_images folder of the release branch. You can either choose to use these images or build your own image by following the steps below.
  • To access the prebuilt_images, click this link : prebuilt_images
  • If you choose to use the prebuilt image, skip the build steps and jump to the test suite execution section below.

Prerequisites

Before starting the ACS build, ensure that the following requirements are met:

  • Ubuntu 18.04 LTS with at least 64GB of free disk space (build on Ubuntu 20.04 is also supported from this version).
  • Must use Bash shell.
  • Build is supported on x86 or aarch64 machines.

Note : Windows build steps will be provided in the future releases.

Perform the following steps to start the ACS build:

  1. Create a directory that is your workspace and `cd' into it.
    $ mkdir <work_dir> && cd <work_dir>
  2. Clone the Arm Enterprise ACS source code.
    $ git clone https://github.com/ARM-software/arm-enterprise-acs.git
    $ cd arm-enterprise-acs
  3. Download and patch LUV OS source code.
    $ ./acs_sync.sh
  4. Build LUV OS and test binaries.
    $ ./luvos/scripts/build.sh

Note:

  • These build steps only target AArch64.
  • The build script provides the option to append kernel command-line parameters, if necessary. Press enter to continue with default parameters.
  • For build options to selectively sync and build particular modules, check this document : build-options.

Build output

The luv-live-image-gpt.img bootable image can be found in: <work_dir>/arm-enterprise-acs/luv/build/tmp/deploy/images/qemuarm64/luv-live-image-gpt.img

This image comprises of two FAT file system partitions recognized by UEFI:

  • 'luv-results'
    Stores logs and is used to install UEFI-SCT. (Approximate size: 120 MB)
  • 'boot'
    Contains bootable applications and test suites. (Approximate size: 60 MB)

The grub-efi-bootaa64.efi netbootable image can be found in: <work_dir>/arm-enterprise-acs/luv/build/tmp/deploy/images/qemuarm64/grub-efi-bootaa64.efi

This image is built to be used in PXE Booting and automatic execution of tests For more details please check this document : build-options.

For more information, see Yocto Project and LuvOS.

Test Suite Execution

Juno Reference Platform

Follow the instructions here to install an EDK2 (UEFI) prebuilt configuration on your Juno board. For additional information, see the FAQs and tutorials here or contact juno-support@arm.com.

After installing the EDK2 prebuilt configuration on your Juno board, follow these steps:

  1. Burn the LUV OS bootable image to a USB stick:
    $ lsblk
    $ sudo dd if=/path/to/luv-live-image-gpt.img of=/dev/sdX
    $ sync
    Note: Replace '/dev/sdX' with the handle corresponding to your USB stick as identified by the `lsblk' command.
  2. Insert the USB stick into one of the Juno's rear USB ports.
  3. Power cycle the Juno.

Fixed Virtual Platform (FVP) environment

The steps for running the Arm Enterprise ACS on an FVP are the same as those for running on Juno but with a few exceptions:

  • Follow the different instructions here to install an EDK2 (UEFI) prebuilt configuration on your FVP.

  • Modify 'run_model.sh' to add a model command argument that loads 'luv-live-image-gpt.img' as a virtual disk image. For example, if running on the AEMv8-A Base Platform FVP, add

    `bp.virtioblockdevice.image path=<work_dir>/arm-enterprise- acs/luv/build/tmp/deploy/images/qemuarm64/luv-live-image-gpt.img'

    to your model options.
    Or,
    To launch the FVP model with script ‘run_model.sh’ that supports -v option for virtual disk image, use the following command:

    $ ./run_model.sh -v <work_dir>/arm-enterprise-acs/luv/build/tmp/deploy/images/qemuarm64/luv-live-image-gpt.img

Automation

The test suite execution can be automated or manual. Automated execution is the default execution method when no key is pressed during boot.
Note: SBBR SCT tests are now included as part of automation. For information about running these tests, see section ‘SBBR SCT tests’ in this document.
The execution varies depending on the test environment. The next set of commands are an example of our typical run of the test suites. Note that the File System Partition in your platform can vary.

The live image boots to UEFI Shell. The different test applications can be run in following order:

  1. UEFI Shell application for SBSA compliance.
  2. SCT tests (if included in the build), for SBBR compliance.
  3. FWTS tests for SBBR compliance.
  4. OS tests for SBSA compliance.

Baselines for Open Source Software in this release:

Security Implication

Arm Enterprise ACS test suite may run at higher privilege level. An attacker may utilize these tests as a means to elevate privilege which can potentially reveal the platform security assets. To prevent the leakage of secure information, it is strongly recommended that the ACS test suite is run only on development platforms. If it is run on production systems, the system should be scrubbed after running the test suite.

License

Arm Enterprise ACS is distributed under Apache v2.0 License.

Feedback, contributions, and support

  • For feedback, use the GitHub Issue Tracker that is associated with this repository.
  • For support, please send an email to "support-enterprise-acs@arm.com" with details.
  • Arm licensees can contact Arm directly through their partner managers.
  • Arm welcomes code contributions through GitHub pull requests. For details, see "docs/Contributions.txt".