Common Questions on SR-DT

[smangali-qc]

HI @chetan-rathore ,

1. Boot Flow: BBSR-LINUX after BBSR-UEFI
   Once BBSR-UEFI completes, the system attempts to transition to BBSR-LINUX with UEFI Secure Boot enabled. However, the DTB authentication fails. We’d like clarification on the following:

      - Is bootaa64.efi signed?
      - If yes, we need the corresponding keys included in the pre-built image to sign the DTB.
      - If no, what is the recommended method to run BBSR-LINUX?
   

We tried clearing the keys, but that causes BBSR-UEFI to trigger again.
2. Linux Distribution Testing
We found the following ARM documentation for Linux distro testing:
🔗 https://developer.arm.com/documentation/DUI1101/4-0/Test-SystemReady-Devicetree-band/Test-installation-of-Linux-distributions?lang=en

We’d like to confirm:

Are we required to test only the distros listed in the ARM documentation?
Can we use the daily ISO builds from these sources instead?
🔗 https://download.opensuse.org/ports/aarch64/tumbleweed/iso/
🔗 https://get.opensuse.org/leap/15.6/

Regards,
Shiva Kumar

[chetan-rathore]

Hi @smangali-qc,

   - Is bootaa64.efi signed?
   - If yes, we need the corresponding keys included in the pre-built image to sign the DTB.
   - If no, what is the recommended method to run BBSR-LINUX?

• Yes the bootaa64.efi is signed.
• Can you provide details on how are you passing the DTB to kernel, we didn't encounter such issue on systems at our side.
• The bbsr-keys used for signing various components of image are included inside the image, in the below path

-- acs_tests
   -- bbsr-keys

We tried clearing the keys, but that causes BBSR-UEFI to trigger again.

• Can you provide more details on the steps and if possible console logs capturing the steps.
• Are you booting with edk2+DT or u-boot
• Did you followed the steps mentioned in bbsr_verification.md to clear the keys https://github.com/ARM-software/arm-systemready/blob/main/docs/BBSR_ACS_Verification.md#disabling-secure-boot-and-rolling-back-to-setup-mode

On the Linux distro questions, I will follow internally and share the details.

[smangali-qc]

HI @chetan-rathore ,

Can you provide details on how are you passing the DTB to kernel, we didn't encounter such issue on systems at our side

after load & auth of the DTB in UEFI at readytoboot event , it will be installed in config table(guid based ) and same is passed to kernel. since we are observing auth failure, DTB image failed to load.

The bbsr-keys used for signing various components of image are included inside the image, in the below path

in this folder, we found that db.key file is missing .

•       while singing the DTB with existing bbsr-keys , we observed this issue : db.key not found and db.cer is ignored 
  

•       after copying these file from **path** from source   to bbsr-keys , we are able to sign , but DTB and EFI are singed with different keys, so again auth failed .
  

•       keys (db.key,db.crt)from source path: ### ### SystemReady-devicetree-band\Yocto\meta-woden\build\tmp\deploy\images\genericarm64\bbsr-keys
  

steps to sign DTB :

     openssl cms -sign  -inkey db.key   -signer db.crt   -binary   -in input.dtb   -out output.sig.dtb  -outform DER

Are you booting with edk2+DT or u-boot

   edk2+DT

Did you followed the steps mentioned in bbsr_verification.md to clear the keys https://github.com/ARM-software/arm-systemready/blob/main/docs/BBSR_ACS_Verification.md#disabling-secure-boot-and-rolling-back-to-setup-mode

   even after keys are cleared as per internal implementation  , then BBSR-UEFI  is triggering once again. it is not allowing to BBSR-Linux.

   could you please copy the right db.key , db.cer used for bootaa64.efi signing in bbsr-keys, then we can try signing the DTB and check the boot up.

   in the below link, DER format, suitable for enrolling in EDK2, but in  bbsr-keys CER is provided, is this old data ?

https://developer.arm.com/documentation/107981/0303/SystemReady-compliance-testing---BBSR-and-Security-Interface-Testing-FAQ/How-do-I-test-for-Base-Boot-Security-Requirements--BBSR--compliance-/Enroll-the-Secure-Boot-keys?lang=en

On the Linux distro questions, I will follow internally and share the details.

  will wait for your response 

[chetan-rathore]

Hi @smangali-qc,

For the Linux Distribution Testing questions,

SRS sheds more light.

The recommended distributions are Fedora, Debian, Ubuntu, RHEL, Rocky Linux, SLES, openSUSE, OpenWrt, and Yocto. When selecting Linux distributions or BSDs, maximize coverage by installing an OS from different groups in the following list. Avoid repetition within groups unless all four groups are covered: • RHEL, Fedora, or Rocky Linux • SLES or openSUSE • Ubuntu or Debian • OpenWrt or Yocto

Daily ISO builds from source can be used.

Thanks,
Chetan

[chetan-rathore]

Hi @sathishas89,

Can you provide more details on the first part of query around the BBSR testing part.

[smangali-qc]

HI @chetan-rathore ,

here are the full details , #458 (comment) ,
let me know if anything is not clear.

Regards,
Shiva Kumar

[smangali-qc]

HI @chetan-rathore ,

any update on this issue.?

Regards,
Shiva kumar

[smangali-qc]

HI @chetan-rathore ,

any update on this issue.?

Regards,
Shiva kumar

[sathishas89]

Hi @shiva kumar,
Please try commenting out the following lines in the file:
https://github.com/ARM-software/arm-systemready/blob/202d1f86b0969069afafc9fd8700b09b4b810fe7/SystemReady-devicetree-band/Yocto/meta-woden/recipes-images/images/woden-image.bb

wic rm ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.wic:1/acs_tests/bbsr-keys/*.crt
wic rm ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.wic:1/acs_tests/bbsr-keys/*.esl
wic rm ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.wic:1/acs_tests/bbsr-keys/*.key

After commenting these lines, please regenerate the SystemReady image.
This updated image should include the db.key and db.crt files in the bbsr-keys directory.

Use this as a temporary workaround for your testing and let me know the results.

Best regards,
Sathisha

[smangali-qc]

HI @Sathisha,

Thank you for the looking into this issue .

we followed the above suggested change, we are able to sing the DTB and authentication is also successfully .

please plan to mainline these changes .

Regards,
Shiva Kumar

[sathishas89]

Hi @shiva Kumar,

We can only ship public keys as part of the ACS package. Including private keys is not recommended due to significant security risks.

If private keys were distributed, there’s a possibility that a partner might accidentally leave the ACS public keys installed in a production system. In such a case, if the corresponding private keys are also available (e.g., from the ACS image), an attacker could use them to sign arbitrary firmware or EFI binaries. This would effectively bypass Secure Boot, compromising the integrity of the platform.

This type of issue has occurred in the industry before, where test or development keys were unintentionally left enabled in released products, leading to serious security vulnerabilities. Therefore, per Arm SystemReady guidelines and general Secure Boot best practices, only public keys (such as .der and .auth files) should be provided in the ACS image for validation and test purposes.

Could you please confirm whether your team is explicitly using a DTB (Device Tree Blob) during boot, or if the platform firmware (e.g., UEFI) is providing the device tree dynamically through the EFI configuration table?
This information will help us assess whether the DTB handling process requires any adjustments to align with the BBSR secure boot flow.

Best regards,
Sathisha S

[smangali-qc]

HI @sathishas,

yes, UEFI install the OS-DTB in EFI configuration table and provide it to kernel. we have to explicitly sign the DTB with the keys which used for EFI image .

if keys are not part of prebuilt, we cannot sign the DTB and subsequently device will fail to boot to shell.

Regards,
Shiva Kumar