Refactoring skeleton flash control

[Abhishek Pandit]

Consolidating my responses to Joel + Patrick.

Joel:

> I imagine you mean the tmpfs (which is backed by SDRAM).


Yes

Have you had input from security/cryptography people for what to do here?


Not yet. I'm preparing the phosphor-flash-control repository (locally) with
a more detailed design README. I'm going to review this internally with a
few people and send out a proposal.
----

Patrick

We have used OpenSSL interfaces for other projects.  I'm not stuck on
> that though.


I just used PGP as an example due to familiarity. Will have more details
once I actually get some security reviews.

---

Re: Software level management

Important use cases (from REST perspective):
>     - How does a user identify which levels are installed?  Which levels
>       are activated?  Which levels are kept for optional downgrade?
>       Which levels are stored on redundant media (ex. dual side flash).
>     - How does a user upload new levels?
>     - How does a user request a level to be activated?


Our traditional approach is host managed. +raltherr might have some more
thoughts on this for more bmc-centric software management.

I think the flash interface will need to be updated to be able to identify
exactly what software on the flash (i.e. Active). I don't know if a single
version for the entire flash (i.e. bmc_v0.1.0) is appropriate or a version
for each individual piece of the bmc image (i.e. uboot_v1.1.0,
kernel_v4.7.11, rofs_v1.2.3). Providing this would probably require some
compile time specialization on the host flash for different architectures.

For the other states (persisted, available, backup, etc), those just seem
like policies and the actual flash interface shouldn't really care about it
(unless the intent is to write the "backup" image to the flash itself).


On Tue, Nov 15, 2016 at 3:39 AM, Patrick Williams <patrick at stwcx.xyz> wrote:

> Abhishek,
>
> On Mon, Nov 14, 2016 at 11:09:30AM -0800, Abhishek Pandit wrote:
> > Hey Adriana,
> >
> > I've started with how I think the dbus interface should behave:
> > https://gerrit.openbmc-project.xyz/#/c/1166/.
>
> I would like to see some better modeling in place for management of code
> levels.  There may be some overlap with what you are proposing, but you
> do seem focused on flashing specifically.  Look this over and let me
> know what you think, how much overlap there is, and how much you want to
> tackle now.  We could do some things like temporarily define the
> interface in org.openbmc, to indicate eventual deprecation, but allow
> you to continue making progress on the function.
>
> -------------------------
>
> Important use cases (from REST perspective):
>     - How does a user identify which levels are installed?  Which levels
>       are activated?  Which levels are kept for optional downgrade?
>       Which levels are stored on redundant media (ex. dual side flash).
>     - How does a user upload new levels?
>     - How does a user request a level to be activated?
>
> Interface modeling:
>     interface xyz.openbmc_project.Software.Level:
>         property - string Name
>                  - string Version
>                  - enum Persistence { "Temporary", "Persisted" }
>                  - enum State { "Loading", "Verified", "Failed",
> "Available" }
>     interface xyz.openbmc_project.FilePath:
>         < Attached to Software.Level object for images resident on the
>           BMC and not in flash modules only. Ex. tmpfs >
>         property - string Path
>
>     interface xyz.openbmc_project.Object.Association:
>         < Associate Software.Level <-> Inventory.Item >
>     interface xyz.openbmc_project.Software.Activation:
>         < Attached to Object.Assocation object >
>         property - enum Activation { "Ready", "Activating", "Backup",
>                                      "Active"
>                    enum RequestedActivation { "None", "Backup",
>                                               "Active" }
>                    integer Progress
>
>     interface xyz.openbmc_project.Object.Add:
>         Used to 'put' new image via HTTPS.  Need to confirm with Brad.
>     interface xyz.openbmc_project.Object.Delete:
>         Used to 'delete' images (from filesystem).
>
> Object modeling:
>     /xyz/openbmc_project/software:
>         Owned by "DownloadManager" which supports Object.Add interface.
> This
>         can be called by REST when a user uploads a new level.  Later,
>         we could attach additional interfaces here, possibly owned by
>         other processes, such as 'Software.DownloadViaTFTP'.
>
>     /xyz/openbmc_project/software/<id>:
>         Owned by "DownloadManager" for images which are resident in
>         tmpfs and a local filesystem ("Available" images).  Owned by
>         "HostUpdater", "BMCUpdater", etc. for images which are resident
>         in flash modules ("Active", "Backup").
>
>     /xyz/openbmc_project/software/<id>/imageFor:
>         Owned by "...Updater" processes and supports the
>         Object.Association and Software.Activation interfaces.
>
> Use case solutions:
>     - How does a user identify which levels are installed?
>         Enumerate /xyz/openbmc_project/software/
>     - ... are activated?
>         List /xyz/openbmc_project/software/ , look at Activation state
>         on assocations.
>     - ... are kept for optional downgrade?
>         List /xyz/openbmc_project/software/ , see images "Persisted",
>         "Available" and not ("Active" or "Backup").
>     - How does a user upload new levels?
>         Do a HTTP PUT to /xyz/openbmc_project/software/<id>.
>     - How does a user request a level to be activated?
>         Set RequestedActivation to "Active", "...Updater" process will
>         begin activation.
> >
> > The overall plan for the flash interface in my head:
> >
> >    - REST (or some other) interface receives image + signature to update
> >    flash
> >       - Gets saved to filesystem and flash control is called
> >    - Flash control loads the files into memory and verifies the signature
> >       - Reference implementation would probably just be pgp
>
> We have used OpenSSL interfaces for other projects.  I'm not stuck on
> that though.
>
> >    - Flash control locks the flash device
> >       - This needs some more thought and probably new dbus interfaces;
> >       important for host flash
>
> Yeah, could certainly be a new interface for this on the same object as
> Software.Activation.
>
> >    - Image written to flash
> >    - Lock on flash device released
> >    - Signal asserted (Done)
>
> Handled by org.freedesktop.Object.PropertyChanged signal on
> "Activation" in my modeling above.
>
> -----------------
>
> This is just what I had floating around in the back of my head of what
> we would [eventually] do for code update.  I have some past experience with
> CIM and I believe this conceptually lines up with what CIM and Redfish have
> both done.  I'm certainly not fixed on any particular interface, property,
> or enumeration names.
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161116/2e937b2e/attachment.html>