Re: BMC Image Signing Proposal

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

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>


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