Preventing Boot Issues on Azure Confidential Computing with Rocky Linux

Selecting Azure Confidential Computing (ACC) for your workload, gives you exceptional security for sensitive workloads on Rocky Linux from CIQ. However, with that added protection comes a few critical things to keep in mind, especially if you're using Confidential OS Disk Encryption.

This guide will help you avoid common issues that can lead to inaccessible VMs and downtime. Prevention is simple once you know what to look out for.

Why this matters

When using encrypted disks, the encryption key is sealed to specific system values (PCRs) during provisioning. These values depend on things like:

• The UEFI firmware

• The Secure Boot shim

• Kernel certificates and signatures

Any unexpected change to these components, even valid ones, can break the key seal. If that happens, your system will fail to unlock the disk automatically, and you'll be stuck at a boot time passphrase prompt via the serial console.

What not to change

To keep your system booting normally, avoid making changes to Secure Boot related components unless absolutely necessary:

Don't change the shim

Rocky Linux from CIQ uses a shim signed by Microsoft and provided by CIQ. Replacing it or using a community version will break the chain of trust.

Don’t install a custom kernel

Only use kernels installed by default with your CIQ image. Custom kernels, even from Rocky Linux's upstream (RESF) or kernel.org, will likely break the boot process.

Avoid untrusted drivers or modules

Some drivers or changes to the initrd can affect the PCRs, even if the system still appears secure.

Set a fallback passphrase

To avoid being permanently locked out, add a custom passphrase to the TPM:

cryptsetup luksAddKey /dev/sdX --token-type systemd-tpm2

Replace /dev/sdX with your encrypted disk (use lsblk to find it). Store the passphrase somewhere safe.

You could test it by forcing a PCR change:

cd /boot/efi/EFI/rocky
mv shim_certificate.efi.bak shim_certificate.efi
reboot

Then use the passphrase in the serial console when prompted. After testing, restore the original shim:

mv shim_certificate.efi shim_certificate.efi.bak

Notes

Consider creating a separate recovery key. This would allow you to unlock the encrypted volume by attaching the VHD to another VM, handy for emergencies.

Always create your fallback passphrase as one of your first steps when deploying a new instance.

Avoid unsupported kernels or unauthorized Secure Boot changes.

Stick with 5th or 6th gen DC- and EC- Azure instance types for full ACC support.

Being proactive helps you stay secure without getting locked out.

References & related articles

Azure Confidential Computing
Data & System Recovery Considerations on Azure Confidential Computing (ACC)