Create AST2600 OTP image

Andrew Jeffery andrew at
Fri Dec 17 09:43:39 AEDT 2021

Hi Jamin,

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/


> 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 
u-boot recipe.

> Do you have any suggestion? Do I need to modify this bbclass, 

No, I don't expect so.


More information about the openbmc mailing list