BMC Image Signing Proposal

[Lei YU]

On Sat, May 19, 2018 at 5:02 AM, Vernon Mauery
<vernon.mauery at linux.intel.com> wrote:
> On 18-May-2018 11:01 AM, Adriana Kobylak wrote:
>>
>> On 2018-05-17 22:33, Lei YU wrote:
>>
>>> So I think it is better for OpenBMC project to have a common (or example)
>>> image signing tools/code, not for a specific machine or product, but for
>>> the
>>> general machines in this project using legacy flash layout.
>>> Let's discuss and get a design proposal?
>>>
>>
>> Yeah, ideally we'd converge the legacy and ubi code update methods into
>> one, to take advantage of the Software D-Bus interfaces and have the
>> different features like signature verification, filesystem mirroring, etc be
>> able to be picked up as separate packages. One starting point for the design
>> proposal would be to determine how to separate in the build and the repo the
>> different code update methods. Lei, want to take an initial stab at it? :)
>
>
> As far as the update methods go, just using a descriptive payload goes a
> long way. Historically, using a manifest type thing that told the update
> mechanism which bytes to write to where was pretty simple and very
> effective. The update mechanism would check the authenticity of the payload
> before trusting the manifest, but then the manifest and payload would all
> get written to the flash. This was for specific flash offsets and did not
> fully comprehend the notion of A/B or other redundant scenarios, so all the
> offsets were relative.
>
> But doing something in the manifest so simple as this would work for a
> variety of scenarios:
>
> MANIFEST:
> purpose=xyz.openbmc_project.Software.Version.VersionPurpose.BMC
> version=v2.2-32-gc6712d3-dirty
> KeyType=OpenBMC
> HashType=RSA-SHA256
>
> # Expected is a list of files alongside the manifest
> Expected=part1,part2,part3,partN
>
> update_pre=<target to activate prior to fwupdate>
>
> # obmc-flash-bmc-by-name knows where to place this part by name
> # (e.g. u-boot always goes at 0x00000000)
> part1_update=obmc-flash-bmc-by-name at .service
>
> # obmc-flash-bmc-at-offset places a part at a fixed offset
> # optionally relative to an optionally specified MTD partition
> # (default relative to /dev/mtd0)
> part2_update=obmc-flash-bmc-at-offset at .service 0x130000
> # (default relative to /dev/mtd0)
> part3_update=obmc-flash-bmc-at-offset at .service 0x130000
>
> # not a ubi person, so I can't comment on all the options :)
> part4_update=obmc-flash-bmc-ubi at .service
>
> partN_update=<service for updating partN>
> update_post=<target to activate post fwupdate>

This is interesting, and it looks like a general method for code updating to
support both non-ubi and ubi layout. (Though it would require code changes in
phosphor-software-manager).

I have several questions though.

Background:
* For non-ubi, there are two ways to do code update:
   1. Copy image-bmc (or image-rofs, etc) to /run/initramfs, and reboot.
      A updater script in initramfs will run to program the image to flash.
      During the code update, BMC is NOT operational;
   2. Invoking "prepareForUpdate" method to ask BMC reboot into a ramfs, then
      invoking the updater script to program the image to flash.
      During the code update, BMC is working.
   3. There is not WebUI support (yet)
* For ubi:
   1. The update happens when BMC is working (due to the fact it assumes the
      flash contains enough space for two images).
   2. The WebUI will upload the image and "activate" it when BMC is running.

So here is my question: to support non-ubifs code update in a general way,
should it do "prepareForUpdate", making BMC to reboot into ramfs, or should it
do the update during reboot?

* If we prefer the "prepareForUpdate" way, then the WebUI should add this
   function to make BMC enter "update" mode;
* If we prefer to update during reboot, then the BMC will not be working for a
   few minutes during the code update, WebUI will not be working as well.

>
>
> The idea is that we can have a series of service files that can handle the
> majority of operations generically and any special cases can supply their
> own. But since it is just a service, the dependencies are all taken care of.
>
>
> Just some thoughts on how this might be done. This is actually something
> that I am working on right now, trying to get our redundant image booting
> working internally, so I am glad to hear that others are working toward
> similar goals.
>
>
> --Vernon