Refactoring skeleton flash control

[Joel Stanley]

Hello Abhishek,

On Tue, Nov 15, 2016 at 5:39 AM, Abhishek Pandit
<abhishekpandit at 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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>