Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-ipmi-flash / 7339e4efa9def1ea8ad6189d6abf62285295dfa9
commit7339e4efa9def1ea8ad6189d6abf62285295dfa9[log] [tgz]
authorPatrick Venture <venture@google.com>Fri May 17 09:13:49 2019 -0700
committerPatrick Venture <venture@google.com>Fri May 17 09:28:58 2019 -0700
treea490f66a76069617a51c1ef3f218e9f61e160db4
parent55646dec5f09c4f5704ed11ef6da5f8fd8bd4427 [diff]
README: drop extra bridge details

Drop extra bridge details from this README as this information is not
kept in the implementation and details that are kept are stored in the
openbmc/docs design.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Ia4c8064e5720efdb7bf6e24d45c95998c10ba995
1 file changed
tree: a490f66a76069617a51c1ef3f218e9f61e160db4
  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. LICENSE
  16. lpc_aspeed.cpp
  17. lpc_aspeed.hpp
  18. lpc_handler.cpp
  19. lpc_handler.hpp
  20. lpc_nuvoton.cpp
  21. lpc_nuvoton.hpp
  22. main.cpp
  23. MAINTAINERS
  24. Makefile.am
  25. pci_handler.cpp
  26. pci_handler.hpp
  27. README.md
  28. 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.