PKCS#11 signing wrapper from rpi-sb-provisioner fails when invoked by rpi-sign-bootcode

[DenysFrasinich]

Describe the bug

Starting from v2.2.0, there is a wrapper script
https://github.com/raspberrypi/rpi-sb-provisioner/blob/v2.2.0/service/rpi-sb-pkcs11-sign.sh
that allows using PKCS#11 to sign the Raspberry Pi bootloader.

During the provisioning process, rpi-sb-provisioner calls rpi-sign-bootcode with the -H parameter and propagates rpi-sb-pkcs11-sign.sh. However, in the rpi-sign-bootcode script propagates the -a parameter to the signing wrapper script:
https://github.com/raspberrypi/rpi-eeprom/blob/a34ba1bcc4f46a2f4c7f3b1e806a238fdacd3698/tools/rpi-sign-bootcode#L125

The problem is that rpi-sb-pkcs11-sign.sh does not accept any parameters except the path to the file containing the data to sign. This causes an error during execution.

P.S. I’m not sure whether this is an integration bug in that project or in rpi-sb-provisioner.

Steps to reproduce the behaviour

1)Create provisioning environment like that instruction says https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/README.adoc on raspberyy. In my setup RaspberryPi 4.
2) generate rsa2048 private key in PKCS#11 capable token, make apropiated changes in /etc/ssl/openssl.conf (pkcs#11 module path, PIN, etc)
3) try to flash CM5
4) look at logs of rpi-sb-bootstrap@.service for errors

Device (s)

Raspberry Pi CM5

Bootloader configuration.

Not related to bootloader directly.

System

No response

Bootloader logs

No response

USB boot

No response

NVMe boot

No response

Network (TFTP boot)

No response

[timg236]

@tdewey-rpi I think this is the expected behavior. The -a flag is used to indicate the algorithm and the HSM wrapper must validate the requested algorithm rather than assuming that it's rsa2048-sha256
It's quite possible that we might might use ECDSA for signing data within the flash image in a future firmware release.