Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-ipmi-flash / 16ab2a1284c79fc17d71ccc0dbc0240741cac070
commit16ab2a1284c79fc17d71ccc0dbc0240741cac070[log] [tgz]
authorPatrick Venture <venture@google.com>Fri May 31 08:52:51 2019 -0700
committerPatrick Venture <venture@google.com>Fri May 31 10:45:00 2019 -0700
tree854a4aefc5c40b1266f59c3958517b83627755f8
parent1a406feadb4bd1063a6c6d5b66a34c30cb953edd [diff]
test: firmware updateStarted: empty and cleanup

Also cleanup the various state goal methods.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I585738781babe55170eaaa3d9e44ed4a076871f9
9 files changed
tree: 854a4aefc5c40b1266f59c3958517b83627755f8
  1. internal/
  2. test/
  3. tools/
  4. .clang-format
  5. .gitignore
  6. .lcovrc
  7. bootstrap.sh
  8. configure.ac
  9. data_handler.hpp
  10. file_handler.cpp
  11. file_handler.hpp
  12. firmware_handler.cpp
  13. firmware_handler.hpp
  14. image_handler.hpp
  15. ipmi_flash.md
  16. LICENSE
  17. lpc_aspeed.cpp
  18. lpc_aspeed.hpp
  19. lpc_handler.cpp
  20. lpc_handler.hpp
  21. lpc_nuvoton.cpp
  22. lpc_nuvoton.hpp
  23. main.cpp
  24. MAINTAINERS
  25. Makefile.am
  26. pci_handler.cpp
  27. pci_handler.hpp
  28. README.md
  29. status.hpp
  30. update.hpp
  31. update_systemd.cpp
  32. update_systemd.hpp
  33. util.cpp
  34. util.hpp
  35. verify.hpp
  36. verify_systemd.cpp
  37. verify_systemd.hpp
  38. window_hw_interface.hpp
README.md

Secure Flash Update Mechanism

This document describes the OpenBmc software implementing the secure flash update mechanism.

The primary details are here.

Introduction

This supports two methods of providing the image to stage. You can send the file over IPMI packets, which is a very slow process. A 32-MiB image can take ~3 hours to send via this method. This can be done in <1 minutes via the PCI bridge, or just a few minutes via LPC depending on the size of the mapped area.

This is implemented as a phosphor blob handler.

The image must be signed via the production or development keys, the former being required for production builds. The image itself and the image signature are separately sent to the BMC for verification. The verification package source is beyond the scope of this design.

Basically the IPMI OEM handler receives the image in one fashion or another and then triggers the verify_image service. Then, the user polls until the result is reported. This is because the image verification process can exceed 10 seconds.

Using Legacy Images

The image flashing mechanism itself is the initramfs stage during reboot. It will check for files named "image-*" and flash them appropriately for each name to section. The IPMI command creates a file /run/initramfs/bmc-image and writes the contents there. It was found that writing it in /tmp could cause OOM errors moving it on low memory systems, whereas renaming a file within the same folder seems to only update the directory inode's contents.

Using UBI

The staging file path can be controlled via software configuration. The image is assumed to be the tarball contents and is written into /tmp/{tarball_name}.gz

TODO: Flesh out the UBI approach.

Configuration

To use phosphor-ipmi-flash a platform must provide a configuration. A platform can configure multiple interfaces, such as both lpc and pci. However, a platform should only configure either static layout updates, or ubi. If enabling lpc, the platform must specify either aspeed or nuvoton.

The following are the two primary configuration options, which control how the update is treated.

OptionMeaning
--enable-static-layoutEnable treating the update as a static layout update.
--enable-tarball-ubiEnable treating the update as a tarball for UBI update.

The following are configuration options for how the host and BMC are meant to transfer the data. By default, the data-in-IPMI mechanism is enabled.

There are two configurable data transport mechanisms, either staging the bytes via the LPC memory region, or the PCI-to-AHB memory region. Because there is only one MAPPED_ADDRESS variable at present, a platform should only configure one. The platform's device-tree may have the region locked to a specific driver (lpc-aspeed-ctrl), preventing the region from other use.

NOTE: It will likely be possible to configure both in the near future.

VariableDefaultMeaning
MAPPED_ADDRESS0The address used for mapping P2A or LPC into the BMC's memory-space.
OptionMeaning
--enable-pci-bridgeEnable the PCI-to-AHB transport option.
--enable-lpc-bridgeEnable the LPC-to-AHB transport option.

If a platform enables p2a as the transport mechanism, a specific vendor must be selected via the following configuration option. Currently, only one is supported.

OptionMeaning
--enable-aspeed-p2aUse with ASPEED parts.

If a platform enables lpc as the transport mechanism, a specific vendor must be selected via the following configuration option. Currently, only two are supported.

OptionMeaning
--enable-aspeed-lpcUse with ASPEED parts.
--enable-nuvoton-lpcUse with Nuvoton parts.

Internal Configuration Details

The following variables can be set to whatever you wish, however they have usable default values.

VariableDefaultMeaning
STATIC_HANDLER_STAGED_NAME/run/initramfs/bmc-imageThe filename where to write the staged firmware image for static updates.
TARBALL_STAGED_NAME/tmp/image-update.tarThe filename where to write the UBI update tarball.
HASH_FILENAME/tmp/bmc.sigThe file to use for the hash provided.
VERIFY_STATUS_FILENAME/tmp/bmc.verifyThe file checked for the verification status.
VERIFY_DBUS_SERVICEverify_image.serviceThe systemd service started for verification.
UPDATE_DBUS_SERVICEupdate-bmc.serviceThe systemd service started for updating the BMC.