BMC Image Signing Proposal

[Vernon Mauery]

On 22-May-2018 08:30 AM, Vernon Mauery wrote:
>On 22-May-2018 02:46 PM, Lei YU wrote:
>>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).

One other thought I had was that we could make the manifest a JSON file 
which makes for very simple parsing (since the parser is already 
written).  Then we could go with something like this:

{
	'purpose': 'xyz.openbmc_project.Software.Version.VersionPurpose.BMC',
	'version': 'v2.2-32-gc6712d3-dirty',
	'KeyType': 'OpenBMC',
	'HashType': 'RSA-SHA256',
	'ImageParts': [
		'part1': {
			'update': {
				'service': 'obmc-flash-bmc-at-offset at .service','
				'args': [ 0x130000 ]
			}
		},
		'part2': {
			'update': {
				'service': 'obmc-flash-bmc-at-offset at .service','
				'args': [ '/dev/mtd/image-a', 0x80000 ]
			}
		},
		'part3': {
			'update': {
				'service': 'obmc-flash-bmc-ubi at .service',
			}
		}
	]
}

This makes it very clear what all the bits mean. We would need to 
document the format of the JSON very clearly and define behavior for 
malformed structures, but I like this better than just a key/value flat 
text file.

--Vernon

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