Refactoring skeleton flash control

Refactoring skeleton flash control

[Abhishek Pandit]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Hey Adriana,

I'm planning on refactoring the skeleton flash update code and pulling it
out into it's own repo (openbmc/phosphor-flash-control).

I've started with how I think the dbus interface should behave:
https://gerrit.openbmc-project.xyz/#/c/1166/.

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
   - Flash control locks the flash device
      - This needs some more thought and probably new dbus interfaces;
      important for host flash
   - Image written to flash
   - Lock on flash device released
   - Signal asserted (Done)

---

For the most part, I don't think I'll rewrite too much of the existing
skeleton code except to have it use the c++ bindings (continue using
libflash and existing MTD devices for bmc update).

Locking the host flash would require some additional thought since
currently it's accessible directly and a mailbox approach would also
require some way to lock the flash when doing read/write.

--

Please take a look at the gerrit. I'll start adding some more information
around locking + signing this week.

Abhishek

[-- Attachment #2: Type: text/html, Size: 1751 bytes --]

Re: Refactoring skeleton flash control

[Joel Stanley]

Hello Abhishek,

On Tue, Nov 15, 2016 at 5:39 AM, Abhishek Pandit
<abhishekpandit@google.com> wrote:
> Hey Adriana,
>
> I'm planning on refactoring the skeleton flash update code and pulling it
> out into it's own repo (openbmc/phosphor-flash-control).
>
> I've started with how I think the dbus interface should behave:
> https://gerrit.openbmc-project.xyz/#/c/1166/.

Great!

I've added to cc Ben and Cyril. They are working on smarter ways to
share access to the PNOR between the Host and the BMC. Your work with
the BMC flash is not affected by what they are doing, there is some
overlap where the PNOR is concerned.

They have a prototype for a system that will own access to the host
flash (aka the  PNOR). Your daemon may end up implementing the
features they describe, or talking to another daemon that manages the
PNOR.

> 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

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

> Flash control loads the files into memory and verifies the signature
>
> Reference implementation would probably just be pgp

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

> Flash control locks the flash device
>
> This needs some more thought and probably new dbus interfaces; important for
> host flash
>
> Image written to flash
> Lock on flash device released
> Signal asserted (Done)
>
> ---
>
> For the most part, I don't think I'll rewrite too much of the existing
> skeleton code except to have it use the c++ bindings (continue using
> libflash and existing MTD devices for bmc update).

Consider dropping the libflash dependency. Where we're only dealing
with mtd devices, the libflash code essentially becomes an
implementation of 'flashcp'.

> Locking the host flash would require some additional thought since currently
> it's accessible directly and a mailbox approach would also require some way
> to lock the flash when doing read/write.

Yep. See my comments above.

Cheers,

Joel

>
> --
>
> Please take a look at the gerrit. I'll start adding some more information
> around locking + signing this week.
>
> Abhishek
>
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>

Re: Refactoring skeleton flash control

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 5072 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Refactoring skeleton flash control

[Abhishek Pandit]

[-- Attachment #1: Type: text/plain, Size: 7045 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10406 bytes --]

Re: Refactoring skeleton flash control

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Wed, Nov 16, 2016 at 05:06:27PM -0800, Abhishek Pandit wrote:
> 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.

Certainly, agree.  I expect different applications for different Host
flash layout schemes.  In fact, for Power, we are strongly considering
not even having the Host-NOR flash actually be laid out in "Power NOR"
format because we are going to use 'memboot' mode.

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

Persisted vs Available is an indication of on-flash or in-tmpfs.
Backup vs Primary may be an indication of dual-sided flash scheme.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Refactoring skeleton flash control

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Wed, Nov 16, 2016 at 05:06:27PM -0800, Abhishek Pandit wrote:
> 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.

Keep in mind that on most systems, the REST API will be present, which
means all DBus interfaces become, by default, available there as well.
This is a big part of why I am proposing the interface model be "data
oriented" rather than "method oriented", for lack of better words.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Refactoring skeleton flash control

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

On Tue, Nov 15, 2016 at 05:39:54AM -0600, Patrick Williams wrote:
> Interface modeling:

Abhishek,

As we discussed last night, I refined and uploaded these interface
models to Gerrit:  https://gerrit.openbmc-project.xyz/#/c/1291/1

I will go through your proposal on Gerrit and try to give you a
comparison between your methods and the ones I'm proposing.  Also as
we discussed, you can decide how much of the ItemUpdater aspects
you are able to implement now vs leaving your proposal as an
'Experimental' interface and we refactor it as we implement other
aspects of my propsal.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]