Future features of phosphor-ipmi-flash

[Patrick Venture]

On Tue, Jul 2, 2019 at 11:00 PM Neeraj Ladkani <neladk at microsoft.com> wrote:
>
> This is great. In this case, we should be able to make use of this design for all BMC managed components ( FPGA, CPLD and PSU FW) by providing verification service, and an update service. Basically TFTP the image and then call the dbus methods

Yes, with phosphor-ipmi-flash, you can send down effectively any
binary you wish and a signature (or without a signature) and then
trigger actions against it, to update anything.  If you do wish to use
it very generically, let me know what you have in mind for a timeline,
and I can plan out the changes.  To make the codebase very generic is
somewhat trivial at this point, it's just a matter of knowing what may
come in the future enough to provide a sufficiently flexible schema
for the json.

>
> How do we specify if we want to update only kernel or rofs or rwfs?

I imagine from reading the code that you can do this, by only dropping
those files into the tarball and leaving out the others.  Maybe the
MANIFEST file's contents specify what's in it in a formatted way?  I
assume so, I don't use bmc-code-mgmt, so I can't say without reading
more of the code, presumably Lei knows.

>
> Neeraj
>
> -----Original Message-----
> From: openbmc <openbmc-bounces+neladk=microsoft.com at lists.ozlabs.org> On Behalf Of Lei YU
> Sent: Tuesday, July 2, 2019 8:18 PM
> To: Patrick Venture <venture at google.com>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Adriana Kobylak <anoo at us.ibm.com>
> Subject: Re: Future features of phosphor-ipmi-flash
>
> On Wed, Jul 3, 2019 at 11:06 AM Patrick Venture <venture at google.com> wrote:
> >
> > Uploading the BIOs via phosphor-ipmi-flash is available for review,
> > but it's not tied into another daemon.  One must provide a
> > verification service, and an update service.
> >
> > I'd like to provide the option to leverage phosphor-bmc-code-mgmt.  It
> > looks like in this codebase there is a notion of a signed image, but
> > the signature is attached.  It also looks like, there's some version
> > information that's meant to parsable and involved.  I haven't had a
> > chance to play with it.
> >
> > With phosphor-ipmi-flash the hash file portion is optional.  Because
> > phosphor-ipmi-flash doesn't define anything beyond the sequence of
> > calls, one could use burn_my_bmc and send the hash down separately and
> > then the verification target could trigger something that concatenates
> > and triggers the bmc code mgmt signature check.
> >
> > It should be somewhat straightforward to tie the two codebases
> > together (as an optional usage).
> >
> > If someone has experience with programming against
> > phosphor-bmc-code-mgmt and wants to help with this or at least point
> > me at what I need to know, I'd be more than happy.
> >
> > From reading the docs with the dbus interface definitions, I think I
> > have the general idea -- drop the file into the place it expects the
> > file (a configuration option) and then call the dbus methods.
>
> Exactly, the whole process of BMC code update is:
> 1. Put a tarball in /tmp/images/ (via REST API, TFTP, or scp) 2. An object will be generated on DBus to represent the image; 3. Invoke a DBus call to set RequestedActivation property to "Active"
> 4. Reboot.
>
> Be noted that the tarball consists of following files:
>
>  image-u-boot
>  image-kernel
>  image-rofs
>  image-rwfs
>  MANIFEST
>  publickey
>  image-u-boot.sig
>  image-kernel.sig
>  image-rofs.sig
>  image-rwfs.sig
>  MANIFEST.sig
>  publickey.sig

Interesting, so it doesn't have to contain all those individual pieces
but could just contain an image-bmc  (which has all the pieces) and
then the signature file.

So in the case of the quanta-q71l we can't use a tarball approach
because there isn't enough memory free to hold the tarball, and the
untarred contents at the same time, and I can't use the /tmp/images
folder because the "mv" command will create a copy before moving and I
also then run out of memory.  The /tmp/images is a configuration
variable in the code-mgmt application, so that part I can get around.
Others aspects, not so much.

However, I want people who are using bmc-code-mgmt already to be able
to use phosphor-ipmi-flash/burn_my_bmc to send down their payloads.
In this case, it can be done very trivially -->

Note: this isn't a ubi tarball update, but that is also supported by
bmc-code-mgmt (I think).

Lei, to use phosphor-ipmi-flash for this, you'd have the verify object
in phosphor-ipmi-flash trigger the "apply" property (and check on the
result somehow) -- I think I saw there's a property for the result.
And you'd have to configure the temporary location variable to be
/tmp/images/ -- you could then send the tarball down to something
like, blob:/flash/statictar and it would know to trigger the things.
-- It will only take one patchset to let burn_my_bmc take any "type"
field that then gets translated directly into the blob.  So today it
doesn't check for a /flash/statictar blob, but it could easily check
for any blob specified. --

phosphor-ipmi-flash expects an image handler, where the bytes are
written, a verification object, and an update object.
 - where the bytes are written, there is a file handler object that
will blindly write bytes, could be used trivially for this just set
destination to whatever.
 - the verification object could trigger the dbus call, it just needs
to be able to report success/failure
 - there is a reboot update object provided that's just "available"
already because we use static image updating presently.

Lei, if I were to provide you some patches in a couple weeks are you
in a position to test?  I'll help you configure your system.  I'll be
busy for the next week, but after that I would like to roll this out
for those already using bmc-code-mgmt.

***Provided the bmc-code-mgmt can report whether it successfully
verified the image against the signature(s).  I think it does, and if
not, I bet it would be easy to add such a property and enum in
phosphor-dbus-interfaces to support this extension.