Re: BMC Image Signing Proposal

[Vernon Mauery <vernon.mauery@linux.intel.com>]

On 22-May-2018 02:46 PM, Lei YU wrote:
>On Sat, May 19, 2018 at 5:02 AM, Vernon Mauery
><vernon.mauery@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@.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@.service 0x130000
>> # (default relative to /dev/mtd0)
>> part3_update=obmc-flash-bmc-at-offset@.service 0x130000
>>
>> # not a ubi person, so I can't comment on all the options :)
>> part4_update=obmc-flash-bmc-ubi@.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).

That was the idea :)

I think that if we really want to converge on some common code here, 
having the phosphor-software-manager handle several different flash 
formats is important. This is the sort of thing that could easily be 
selectable at build time, one method should have little impact on the 
other.

>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;

Intel has a requirement to do firmware updates while the BMC is active, 
so we will need to enable this feature in the WebUI. This is not a hard 
problem, given that a redfish mechanism is already in the works.

--Vernon

>* 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