Create AST2600 OTP image
andrew at aj.id.au
Fri Dec 17 09:43:39 AEDT 2021
On Thu, 16 Dec 2021, at 17:11, Jamin Lin wrote:
> Hi OpenBMC team
> I have some questions about OTP image creation in OpenBMC. To support
> AST2600 RoT(Root of Trust, AST2600 ROM code verified SPL), users should
> program "A public key" in OTP and uses "A private key" with SPL image
> to create signature and place it in SPL.
> The SOCESEC tool help user to create OTP and SPL images for AST2600
> secure boot support.
> The following are my questions and solutions
> 1. There was a socsec-sign.bbclass in OpenBMC and it is used for SPL
> image generation with SOCSEC tool. Do you agree if I modify
> socsec-sign.bbclass to create OTP image?
I'm not convinced on this one. While the OTP configuration and the
output of the socsec signing process are tightly coupled they involve
separate processes. Off the top of my head, the fact that socsec and
otptool are separate utilities suggests to me that they should use
separate bbclasses in the build process.
> If no, I will try to use solution 2.
This is the path you should follow - I have some comments below.
> 1. I will create a new recipe to create OTP image and this recipe
> will be placed in meta-aspeed/recipes-aspeed/otp/otp.bb
> To successfully build the OTP and SPL images, we should create the
> key-pair one for OTP(public key) and another for SPL(private key).
> Do you have any suggestion to place these keys in where?
> 1. So far, we placed both private key and public keys here,
> How to get the public key in OTP recipe? It seems I need to place
> public key,
> in meta-aspeed/recipes-aspeed/otp/files and private key in u-boot,
We might need a separate recipe e.g. called 'aspeed-ast2600-rot-keys',
and move the files you've pointed to above into that recipe. From there
both the OTP and u-boot recipes can depend on 'aspeed-ast2600-rot-keys'
to gain access to the files.
> 1. The socsec tool settings should be consistent. For example: If
> user set the algorithm "RSA4096_SHA512" in SPL, it is required to use
> the corresponding *.json config in OTP.
Yes, but maybe this creates too many headaches to enforce? We'd have to
parse the json and line it up with SOCSEC_SIGN_ALGO in the recipe. It
seems much easier if we just do a `socsec verify ...` once we've
generated all the artefacts, feeding in the OTP image we've also built
through the otptool bbclass. If the verification fails then the build
fails and someone can look at what happened.
> By default, it set SOCSEC_SIGN_ALGO ?= "RSA4096_SHA512" to create SPL,
> it is required to use
> for OTP image generation.
This isn't true. How I want this to work is that each platform provides
its own OTP json configuration, and the otptool bbclass consumes that
to produce the OTP image.
Platform designers should have the freedom to pick their own
platform-specific OTP settings with respect to e.g. the ABR, boot
source fallback, secureboot etc features. There's no point generating
the cartesian product of configurations out of the box, it would just
be confusing and a *huge* amount of noise.
I've cooked up a platform-specific config for our p10bmc systems for
instance, and was planning on integrating that into the OpenBMC tree.
> How to share the environment variable between u-boot and otp recipes?
> Do you prefer to add "SOCSEC_SIGN_ALGO" in machine configuration
> file, so this variable can be recognized between otp and u-boot recipes.
> Do you have any suggestion?
It should be set by the platform config and so should be available to
any recipe executed in the build process, included e.g. an otptool
recipe. Platform bitbake configs shouldn't rely on any particular
default value being set in socsec-sign bbclass for SOCSEC_SIGN_ALGO (we
might change the default in the future - then any platforms relying on
a particular default value would break).
> 1. How to trigger the build process to build create OTP image if
> user only issues "bitbake obmc-phosphor-image"?
> Our solution set the do_generate_static_tar task dependencies. So,
> build process create the otp image first, then run
> do_generate_static_tar task.
You probably want to add it as a dependency of u-boot. This way the
socsec-sign bbclass can implement the functionality to run `socsec
verify ...` with the OTP blob as its last step, triggered from the
> Do you have any suggestion? Do I need to modify this bbclass,
No, I don't expect so.
More information about the openbmc