Secure container production mode PNOR is failing with illegal option parsing while signing command

[PavamanSubramaniyam]

We are using our Jenkins CI to generate Secure container creation production mode PNOR using the upstream op-build git tree.

11:09:08 TRACE: /home/jenkins_data/OPAL/prodmode/op-build/output/host/usr/bin//crtSignedContainer.sh --scratchDir /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch/ --mode production --hwPrivKeyA __get --hwPrivKeyB __get --hwPrivKeyC __get --swPrivKeyP __get   --flags 0x80000000 --sign-project-FW-token HBBL  --protectedPayload /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//HBBL.staged --out /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-1968946895.HBBL.temp.hdr.bin
11:09:08 /home/jenkins_data/OPAL/prodmode/op-build/output/host/usr/bin//crtSignedContainer.sh: illegal option -- -
11:09:08 
11:09:08     Options:
11:09:08     -h, --help              display this message and exit
11:09:08     -v, --verbose           show verbose output
11:09:08     -d, --debug             show additional debug output
11:09:08     -w, --wrap              column to wrap long output in verbose mode
11:09:08     -a, --hwKeyA            file containing HW key A private key in PEM format
11:09:08     -b, --hwKeyB            file containing HW key B private key in PEM format
11:09:08     -c, --hwKeyC            file containing HW key C private key in PEM format
11:09:08     -p, --swKeyP            file containing SW key P private key in PEM format
11:09:08     -q, --swKeyQ            file containing SW key Q private key in PEM format
11:09:08     -r, --swKeyR            file containing SW key R private key in PEM format
11:09:08     -l, --protectedPayload  file containing the payload to be signed
11:09:08     -i, --out               file to write containerized payload
11:09:08     -o, --code-start-offset code start offset for software header in hex
11:09:08     -f, --flags             prefix header flags in hex
11:09:08     -m, --mode              signing mode: local, independent or production
11:09:08     -k, --kms               key management system for retrieving keys and signatures
11:09:08                             (choices are "signframework" or "pkcs11")
11:09:08     -s, --scratchDir        scratch directory to use for file caching, etc.
11:09:08     -L, --label             name or identifier of the module being built (8 char max)
11:09:08         --contrHdrOut       file write container header only (w/o payload)
11:09:08         --archiveOut        file or directory to write archive (tarball) of artifacts
11:09:08                             if directory, must end in '/'.  for PWD, use '.'
11:09:08         --archiveIn         file containing archive of artifacts to import to cache
11:09:08         --validate          validate the container after build
11:09:08         --verify            verify the container after build, against the provided
11:09:08                             value, or filename containing value, of the HW Keys hash
11:09:08         --sign-project-config   INI file containing configuration properties (options
11:09:08                                 set here override those set via cmdline or environment)
11:09:08 
11:09:08 Error running command: /home/jenkins_data/OPAL/prodmode/op-build/output/host/usr/bin//crtSignedContainer.sh --scratchDir /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch/ --mode production --hwPrivKeyA __get --hwPrivKeyB __get --hwPrivKeyC __get --swPrivKeyP __get   --flags 0x80000000 --sign-project-FW-token HBBL  --protectedPayload /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//HBBL.staged --out /home/jenkins_data/OPAL/prodmode/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-1968946895.HBBL.temp.hdr.bin. Nonzero return code of (256) returned.

[PavamanSubramaniyam]

------------------------------------------------------------------------------------------------------------------------
TEST PROCEDURE:
------------------------------------------------------------------------------------------------------------------------

1. Clone the op-build repository and cd to the directory:

   $ git clone --recursive https://github.com/open-power/op-build.git
   $ cd op-build/

2. Source the op-build environment file and load the platform configuration to test (e.g. witherspoon)

   $ source op-build-env
   $ op-build witherspoon_defconfig

3. If running the test non-interactively, unencrypt your SSH key and patch the signframework client to use the unencrypted key, as shown in SETUP.  ONLY DO THIS FOR TEST OR DEVELOPMENT KEYS, *NEVER* DO THIS WITH PRODUCTION KEYS OR PRODUCTION SIGNING OPERATIONS.

4. Set the location of the project INI file:

   $ export SB_PROJECT_INI=/path/to/project.ini 

5. Run op-build in Production mode.  The signtool will connect to the signframework as needed, to retrieve the required keys and signatures.  If not running with the unencrypted SSH key, you will be prompted for your password on each signframework request.

   $ op-build BR2_OPENPOWER_SECUREBOOT_SIGN_MODE=production

[PavamanSubramaniyam]

@bofferdn @hellerda Could you please have a look on this issue.

[hellerda]

This is probably due to your CI system pointing to the latest head of sb-signing-utils master instead of the tagged version v0.5. (see openpower/package/sb-signing-utils/sb-signing-utils.mk). While I know you have been pointing to the latest instead of the tagged version because it is helpful for CI, at the moment, the latest sb-signing-utils won't work with some machine configs (e.g. witherspoon_defconfig) until their BR2_HOSTBOOT_STABLE_VERSION is advanced to commit adc91be44 or later.

Sorry for the trouble but it is currently out of my control. I am blocked from advancing the SB_SIGNING_UTILS_VERSION in op-build to my next tagged version, for the same reason.

You can revert your SB_SIGNING_UTILS_VERSION to "v0.5" in the interim, as workaround. If you see a failure with v0.5 of course let me know. Thx -DaveH

[pridhiviraj]

@hellerda Yes, it is failed due to upstream sb-signing-utils master one. We made that as a default in the CI. Let me re-trigger with default op-build tagged version v0.5.

[hellerda]

This should be fixed now with the acceptance of sb-signing-utils v0.6 into op-build, with PR #2371.

You should be able to point to the new op-build default (v0.6), or point again to "master" of sb-signing-utils, which I would prefer. That way I can see when things break. ;- ) At the moment there is no difference.

Sorry for the trouble, I got caught between versions of hostboot, on which sb-sigining-utils relies. (the buildpnor scripts, anyway).