OpenBMC Image Management

[Chris Austen]

"openbmc" <openbmc-bounces+austenc=us.ibm.com at lists.ozlabs.org> wrote on
01/25/2017 04:15:27 PM:

> From: Adriana Kobylak <anoo at linux.vnet.ibm.com>
> To: openbmc at lists.ozlabs.org
> Date: 01/25/2017 04:32 PM
> Subject: OpenBMC Image Management
> Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com at lists.ozlabs.org>
>
> Hi,
>
> Here is a first draft proposal for image management (code update) in
> OpenBMC for feedback.
>
> General:
> * Move to UBI volume management (on the BMC and PNOR chips), which
> provides dynamic partitioning and wear-leveling. In a limited flash
> space environment there might be the need to re-allocate partition
> space and resizing in a static partitioning implementation can be
> very painful.
> * Use CRAMFS for read-only partitions, and UBIFS for read-write
partitions.
>
> PNOR:
> * Implement a new mboxd based on Cyril’s (see Cyril’s email “Mailbox
> daemon”) that handles dbus objects, generates a virtual PNOR for UBI
> content, etc.
> * Move to memory-based access instead of the current LPC-to-AHD path.
> * Allocate just enough space in the initial window for Hostboot’s
> TOC, HBB, and HBI partitions, grow as required.
> * Ability to ‘patch’ by copying a Hostboot image *.bin into a
> designated directory (/usr/local/ for example).
> * Tool to write from PNOR image to BMC format. Implement UBI
> initially but it could be extended to support different volume
> managements on other BMCs.
>
> BMC:
> *Save multiple firmware versions, starting with 2, to provide the
> ability to roll-back if needed. If single BMC chip system, save both
> versions there. If two BMC chip system, save other version in 2nd chip.
> * Implement various levels of ‘persistency’, such as dev, factory,
> field. Dev persistency would allow for local patches (/usr/local/
> for example) that can be cleared before shipping to customers.
> Factory mode could delete the location where user data such as
> network settings resides but preserves the mac address and uuid for
> example. Etc.
>
> Thanks,
>
> Adriana
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc


So are the goals of Image Management..

1) Actively manage wear-leveling
2) Provide an api for BIOS/Host inband update
3) Provide a way to boot an image that is not from flash
4) Duel image support
5) Duel flash chip support
6) Support multiple tiers of sanitization

Are there any security goals that need to be considered?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170125/44a2cb8e/attachment.html>