OpenBMC Image Management

[Rick Altherr]

Applying patches makes for a security problem as well. Verifying integrity
and authenticity of the rootfs requires having trusted hashes. dm-verity
does this at a filesystem level. Patching individual binaries would
invalidate the signatures.

On Jan 26, 2017 7:36 AM, "Adriana Kobylak" <anoo at linux.vnet.ibm.com> wrote:

>
> On Jan 26, 2017, at 4:43 AM, Anton D. Kachalov <mouse at yandex-team.ru>
> wrote:
>
> Hello.
>
> 26.01.2017, 01:32, "Adriana Kobylak" <anoo at linux.vnet.ibm.com>:
>
> General:
> * Use CRAMFS for read-only partitions, and UBIFS for read-write partitions.
>
>
> Why CRAMFS? It's small, but supports only zlib compression, has a 16MB
> file size limitation and marked as obsolete in kernel tree. Why not
> SquashFS? It's better for larger projects, has a number of modern
> compression algos.
>
>
> You’re right Anton, typo mistake, it should be SquashFS, not CRAMFS.
>
>
> PNOR:
> * Ability to ‘patch’ by copying a Hostboot image *.bin into a designated
> directory (/usr/local/ for example).
>
>
> Would it be good to add support for opkg-based packaging to incrementally
> (hotfix) system's update? I use it in OpenWRT.
>
>
> It is a good point, for this we’d need a read-write filesystem to contain
> the code, and be more formal in updating the revision number in bitbake for
> the images (currently is set to 0). But since our current use case is about
> applying temporary (development) patches, not permanent fixes, these
> changes wouldn’t be a priority at the moment. Also for PNOR images, we
> don’t own the packaging process (it’s done by the hostboot build).
>
> As additional information, I’ll be sending a more detailed flow of the
> PNOR update, including how the dbus objects in Patrick’s Software.Version
> yaml specification would fit, and how to create the virtual PNOR for the
> host (memory piece) that the mboxd will be interacting with.
>
>
> * 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
>
>
> --
> Anton D. Kachalov
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170126/45a96a00/attachment.html>