add image repackaging for secure boot

[dcasota]

Is your feature request related to a problem? Please describe.

Afaik there is no built-in Secure Boot functionality for Photon OS Installer. A first step would be a way to unpack and repack an image to either with custom keys or with a signed boot loader.

Describe the solution you'd like

Functionality for Photon OS installer secure boot

• uefi secure single boot, uefi secure multi-boot with hard disk encryption as an option
• bi-boot mbr/uefi secure boot
• automatic signing
• key replacement

Support of Photon OS biased images during make build and for post-image-creation unpack and repack of to either with custom keys or with a signed boot loader.

A sort of one-fits-them-all is not the goal. The suggestion is a wish list.

Describe alternatives you've considered

options considered

• Set up secure boot with systemd-ukify
• Set up secure boot with sbctl

Additional context

systemd-ukify

The systemd developer team actually work on a sort of unified kernel image bundle functionality, see e.g. systemd/systemd@83bf58f.
Not yet implemented in Ph5.

sbctl

Sbctl has more manual steps and more restrictions, but yes, it works on Ph5.

# a2x is missing in Photon OS' asciidoc3 package. This is a prerequisite for sbctl. Use the python setup of asciidoc which contains a2x.
tdnf install -y python3-pip docbook-xsl
pip3 install asciidoc

# sbctl
tdnf install -y go util-linux binutils libxslt tar build-essential git
VERSION=0.16
curl -L "https://github.com/Foxboron/sbctl/releases/download/${VERSION}/sbctl-${VERSION}.tar.gz" | tar zxvf -
cd "sbctl-${VERSION}"
make
make install
cd ..

# cleanup
rm -rf "sbctl-${VERSION}"
rm sbctl-${VERSION}.tar.gz
pip3 uninstall -y asciidoc
tdnf remove -y go binutils libxslt docbook-xsl tar build-essential git

Remarks

Rethinking the situation of Photon OS on Dell IoT gateway in 2015, the secure delivery of firmware bits through updates of a secure boot operating system seems to become more affordable.

In addition, with the deadline of October 19th 2026, all Microsoft UEFI certificates 2011 will fail. This can be checked with pwsh
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows Production PCA 2011'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Older Microsoft appliances on VVF/VCF won't boot properly if not patched including its recovery boot bits. Many companies are familiar to use static, older images. This could be the case after that deadline as well. With such a built-in functionality in Photon OS Installer however, pressure could be cushioned for the VCF/VVF business. It would be nice to have something like a VMware Converter for Secure Boot Conversion. From an embedded license perspective see github.com/microsoft slash secureboot_slash objects/issues/138.

[YustasSwamp]

Photon OS SB implementation is pretty much locked down, with minimal to no flexibility.
Our bootloader binaries (shim + grub) are signed out of the box. SB enabling should be performed from VM settings (.vmx file)
It makes sense to add "Secure Boot enable" option in POI @oliverkurth .
Regarding additional features:

• bi-boot mbr/uefi secure boot == is already support by POI.
• automatic signing == there is no signing step at POI stage. All required binaries in RPMS are already signed: shim by MS, grub+kernel by our vendor key on time we built these RPMS. Kernel modules can be signed by us, product teams or our partners. Unfortunately signing jobs are not available for external users. To get SB working you need to consume shim+grub+kernel images build by Photon team.
• key replacement == for key revocation we use UEFI black lists such as DBX. For key addition, Only supported model is to add trusted key/cert in kernel keyrings. No other UEFI keys management.
• Unified kernel == we didn't received such request from product teams
• sbctl == as well as mokutil will not be supported. 2 contributing factors why: such functionality is not required for any VMware products, and it opens up additional security risks.
• UEFI CA 2011 key == we have a plan to move to latest EUFI CA cert once new version of shim ready, which will be compliant with new MS requirements.

[oliverkurth]

It makes sense to add "Secure Boot enable" option in POI @oliverkurth .

We have the option, in open-vmdk. See this example ova config file: https://github.com/vmware/photon-os-installer/blob/master/examples/ova/minimal_ova.yaml#L6 . Just set secure_boot: True. It will set the vmx config bootOptions.efiSecureBootEnabled to true.

[dcasota]

Hi Alexey and Hi Oliver,

In any case, I have considered myself and continue to consider myself a loyal partner, although without executive power in Broadcom's commercial sense.

VVF environments

I am aware of the plan to keep secure boot functionality in the virtualization layer. This has worked well in the past and created security for data center virtual hardware release upgrades.

The possibilities are

• Platform Key, PKDefault
• Key Exchange Key, KEKDefault
• Signature Database, dbDefault
• Revoked Signatures Database, dbxDefault
  • get UEFI Revocation List File for x64/Arm64 from https://uefi.org/revocationlistfile
  • https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin
  • https://uefi.org/sites/default/files/resources/arm64_DBXUpdate.bin

Hence, e.g. for the signature database, the following modifications are possible

uefi.secureBoot.dbDefault.file0 = "custom certification.der" #file1, file2, ... as well
uefi.secureBoot.dbDefault.value0 = "[fill-in]"
uefi.secureBoot.dbDefault.append = "TRUE"

With that in VVF environments, it is easy for POI to "forward" secure boot functionality. Encryption not. POI is standalone with offline capability and not as a service.

In nowadays, Secure Boot embraced Edge as well.
But unfortunately, Broadcom/VMware is not listed in edge hardware efi-var -L.
The idea of this enhancement is to get more functionality bakened into POI. If it matches to ~Unfortunately signing jobs are not available for external users, all fine. I agree, remembering photon case initiative 1389. It must cost something,

Btw. Shim 15.8 with dhcp doesn't work yet flawlessly.

non-VVF environments

On e.g. Azure, Secure Boot with Encryption driven by POI is not possible.
The 'UEFI CA 2023 + 2011 revocation' use case in non-VVF scenarios 'firmware > bootloader> linux kernel>root filesystem' is not defined yet for Photon OS, right?

Cyber Resilience Act

Kernel modules can be signed by us, product teams or our partners.
It's not about signing. But to have a secure path for more use cases. It's a pity seeing companies doing the same for their own again and again for Cyber Resilience Act purposes. They are preparing for this not by using existing hypervisor technologies but to integrate Secure Boot in their own bits. To get an idea, see e.g. Toradex OS, Yocto OS, etc.

conclusion

If the suggestion was bad, please close the case. I'm not doing this to chat. I care about this Broadcom product.