Proper Secure Boot support

[pbatard]

In case you haven't seen how we do it on the Pi, this is relatively easy to add during the EDK2 build process.

Basically you want to first get all the needed Secure Boot certificates and dbx, most of which can be downloaded directly: https://github.com/pftf/RPi4/blob/master/.github/workflows/linux_edk2.yml#L50-L58

Note that, because we sure don't want any third party (including ourselves) to have control over somebody else's machine when it comes to Secure Boot, we always generate a new PK as part of the build process and then discard the private key altogether.

Then, at EDK2 build time, you just need to feed the -D SECURE_BOOT_ENABLE=TRUE option along with something like -D DEFAULT_KEYS=TRUE -D PK_DEFAULT_FILE=$WORKSPACE/keys/pk.cer -D KEK_DEFAULT_FILE1=$WORKSPACE/keys/ms_kek.cer -D DB_DEFAULT_FILE1=$WORKSPACE/keys/ms_db1.cer -D DB_DEFAULT_FILE2=$WORKSPACE/keys/ms_db2.cer -D DBX_DEFAULT_FILE1=$WORKSPACE/keys/arm64_dbx.bin: https://github.com/pftf/RPi4/blob/master/.github/workflows/linux_edk2.yml#L64-L65

And with this, you should have a UEFI firmware that both Windows and Linux are happy with when it comes to Secure Boot.

[mariobalanica]

Thanks for input, Pete!

I've actually put this on hold because we don't have a secure var store, and there are more steps involved to ensure a trusted boot chain that I'm not sure many would bother with.

But yeah, some formal support in EDK2 to make Windows happy and satisfy one of the requirements is better than nothing.

[pbatard]

Oh yeah, you're never going to get to a proper trusted boot chain on SoC systems without a lot of extra work, and we are well aware that, at least for the Pi, the Secure Boot feature we provide is more a showcase than anything that will actually help "secure" the system. It was indeed mostly added so that people could get Secure Boot status: On when running WoR...

[mariobalanica]

Added initial support in: 8b6b3a6242af7ef37358d98b6918bfd11b52173e

Will keep this open to track further progress.

One obvious thing that needs to be fixed is disabling the recently added FDT override support when SecureBoot is on, since those files aren't signed. But it may be desirable to leave it this way until work on mainline Linux and DT settles, so folks won't have to rely on overrides as much.

[hongkongkiwi]

@pbatard Does the above method work without code modifications just passing the extra arguments? how can I sign a linux image I want to securely boot?

[pbatard]

The above method is for adding the Secure Boot certificates to a UEFI firmware that you build yourself. It has nothing to do with signing a linux image to work with an existing UEFI firmware that you did not build. If you do build your own UEFI firmware from scratch you should however be able to install your own certificate by adding an extra -D DB_DEFAULT_FILE3=my_cert.cer, and then whatever you sign with the private key that matches the one from this public cert should be validated under Secure Boot.

OR, and I assume this is really what you actually want to accomplish, if you are not building a UEFI firmware from scratch, but just want to have something you sign work with an existing UEFI firmware, you should follow this extensive guide to add your own certs using the existing UEFI interfaces.

[hongkongkiwi]

Makes sense, thanks for the link. That clears up signing downstream.

But for upstream, I am interested to use the builtin eFuse on Rockchip to make sure that only my custom signed bootloader can be used.

I've seen this done successfully with U-Boot and the rockchip signing tools (they sign the idbloader.img file). In our case, is the idblock.bin an equivalent of that?

[pbatard]

I'm afraid you're going to have to ask somebody else about this, as I know nothing about idblock.bin and I am not involved in RK3588 development.

[DualTachyon]

@hongkongkiwi you want this I guess: https://github.com/DualTachyon/rk3588-secure-boot

[hongkongkiwi]

Very helpful! Thanks @DualTachyon