BMC Image Signing Proposal

[Lei YU]

On Fri, May 25, 2018 at 1:12 AM, Adriana Kobylak <anoo at linux.ibm.com> wrote:
> On 2018-05-22 13:28, Vernon Mauery wrote:
>>
>>
>> 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:
>>
>
> That's a good option, at least for the write to flash piece. We could
> even extend the manifest to include the names of the service files to
> delete/clean up the flash. Most of the rest of the code manages the
> D-Bus objects so that'd be common with all flash layouts.
>
> Another option, or combination with a json manifest, would be to have
> different repos or different subdirectories for specific implementations.
>
>
> Lei, thinking we could convert Romulus to ubi, and use the PNOR chip
> to store the alternate BMC version. I think that'd be more straight fwd
> and the advantage would be that the interfaces are tested and verified.
> And on the side we can continue this discussion on how to make the
> code more modular to support other layouts and we can start making
> the changes but at least we can get Romulus using signature validation
> in the mean time.

By default Romulus has a single 32MiB for BMC and 64MiB for PNOR, there is not
enough room for Romulus to enable ubi with alternative BMC.
So I am afraid that it can not enable ubifs.

But I do have enabled image signature verification on fixed layout and tested
on Romulus.

The related changes are:
https://gerrit.openbmc-project.xyz/#/c/10765/
https://gerrit.openbmc-project.xyz/#/c/10801/
https://gerrit.openbmc-project.xyz/#/c/10768/
https://gerrit.openbmc-project.xyz/#/c/10800/

I have tested on Romulus that:
* Code update successful with valid image, both REST API and in WebUI;
* Code update failure with invalid image (signature verify failure), if
   FieldMode is enabled;

I you think that is OK, we can merge the changes, as it adds the new features
(code update and signature verify in phosphor-software-manager) without
breaking existing services.
It could be a start point for phosphor-software-manager to handle both ubifs
and non-ubifs.

Then we can continue to work on enhancing/refactoring to make it more generic
as Vernon suggested.