BMC image generation without private key
yulei.sh at bytedance.com
Wed Jan 18 23:20:13 AEDT 2023
On Wed, Jan 18, 2023 at 8:10 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> On Mon, Jan 16, 2023 at 05:53:40PM +0800, Lei Yu wrote:
> > The OpenBMC build requires a private key to:
> > 1. Generate the public key that is put in the image;
> > 2. Sign the image and generate the whole tarball.
> > For dev builds, it uses the insecure development key in the tree.
> > For release builds, it requires the `SIGNING_KEY` env to point to a
> > secure key to sign the image.
> > It is considered insecure because it requires the build server to
> > access the private key.
> > An alternative is proposed:
> > * A new `SIGNING_PUBLIC_KEY` env is defined to point to a public key.
> > * The above key is default to empty, and the behavior is the same as
> > before, using the insecure development key to generate and sign the
> > image.
> > * With a valid `SIGNING_PUBLIC_KEY`:
> > * The public key is installed into the BMC image.
> > * The generated tarball is not signed, only containing the MANIFEST
> > and the image.
> > * A new `gen-bmc-tar` tool will be introduced to sign the above
> > tarball, like `gen-bios-tar`.
> > * If both `SIGNING_PUBLIC_KEY` and `SIGNING_KEY` is set, throw an error.
> > With the above proposal, the build does not require the private key
> > anymore and the user could install the public key during build, and
> > sign the image separately.
> > Comments are welcome.
> I don't have much opinion on this if you think it is the right direction
> for your purposes.
The patches related to SIGNING_PUBLIC_KEY are sent to:
The singing mentioned above is related to the tarball and is verified
during BMC code update.
It does not involve the verification on BMC boot (which is a different topic).
> My companies' existing signing system does not rely on the signatures
> done during the build. The output of our build is a single MTD image,
> with a FIT image. When we want to sign the image, we [external to the
> build] extract the FIT signature device tree, re-sign it, and update the
> MTD with the new signature set.
> I've recently added some of the code upstream that eliminates the
> separate rootfs and puts everything into a single initramfs. This is
> still in-progress but I plan to have it mostly complete by the end of
> the month.
This is interesting, this means a new flash layout, is it?
> 1. https://gerrit.openbmc.org/q/topic:no-rootfs
> 2. https://gerrit.openbmc.org/c/openbmc/openbmc/+/60110
> Patrick Williams
More information about the openbmc