| commit | d9fb61378320672bb3cebdbb9ec246087cd70b87 | [log] [tgz] |
|---|---|---|
| author | Patrick Venture <venture@google.com> | Thu Nov 08 09:56:10 2018 -0800 |
| committer | Patrick Venture <venture@google.com> | Thu Nov 08 10:03:58 2018 -0800 |
| tree | 486fad3dfbe545ea1affb625dab1386a3a8458ba | |
| parent | e2e5611bd19b313cffb6a2ce9a8e3a18a4e71b88 [diff] |
firmware: add a session lookup map Add a session lookup map for use in session-based commands to retrieve the session structure, which holds pointers to the handlers for copying from and writing to. Add two persistent Session objects to the firmware handler, since we only will ever have two sessions at a time. An active image and an active hash. Change-Id: Ib0029f693266fa3df961275bae5c61b205cfa42d Signed-off-by: Patrick Venture <venture@google.com>
This document describes the OpenBmc software implementing the secure flash update mechanism.
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 in the Google OEM number space: 11129. This is also implemented under the Firmware netfn.
It is command: 127
The OpenBmc tool, not yet upstreamed, supports this approach.
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.
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.
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.
To determine if the bridge sequence is supported you can send the FlashRequestRegion subcommand and see if it returns success with an address. However, for the sake of sanity, there is also a FlashVersion subcommand that'll return the version of the protocol.
If you're updating the image entirely over IPMI, then you should expect to send the following sequence of commands:
FlashStartTransferFlashDataBlock (for each piece of the image)FlashDataFinishFlashStartHashFlashHashData (for each piece of the hash)FlashHashFinishFlashDataVerifyFlashVerifyCheck (repeatedly until it results with 3-5s sleeps)If you're using some region to send the image and hash, you should expect to send the following sequences of commands:
FlashStartTransferFlashMapRegionLpc(if necessary)FlashRequestRegionFlashDataExtBlock (for each piece of the image)FlashDataFinishFlashStartHashFlashHashExtData (for each piece of the hash)FlashHashFinishFlashDataVerifyFlashVerifyCheck (repeatedly until it results with 3-5s sleeps)The PCI-to-AHB bridge is only available on some systems, and provides a 64-KiB region that can be pointed anywhere in BMC memory space.
It is controlled by two PCIe MMIO addresses that are based on BAR1. Further specifics can be found in the ASPEED data sheet. However, the way it works in this instance is that the BMC has configured a region of physical memory it plans to use as this buffer region. The BMC returns the address to host program so it can configure the PCIe MMIO registers properly for that address.
As an example, a 64-KiB region a platform can use for this approach is the last 64-KiB of the VGA reserved region: 0x47ff0000.
Like the P2A mechanism, the BMC must have already allocated a memory region with a platform-defined size. This region is mapped to LPC space at the request of the host, which also specifies the LPC address and region size in the mapping request subcommand. The host can then read the actual LPC address at which the BMC was able to map, checking that it's usable.
As future work, USB should be considered an option for staging the image to be copied to the BMC.
The following details each subcommand with which you'll lead the body of the command. Unlike some designs, the responses don't necessarily include the corresponding sub-command, partially because this protocol is meant to be used by one user at a time and trying to use otherwise can have negative effects and is not supported.
In the following, any reference to the command body starts after the 3 bytes of OEM header, and the 1-byte subcommand.
This will now also go after the firmware function.
The FlashStartTransfer command expects to receive a body of:
struct StartTx
{
uint32_t length; /* Maximum image length is 4GiB */
};
However, this data is presently ignored.
This command will first close out and abort any previous attempt at updating the flash.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects to receive a body of:
struct ChunkHdr
{
uint32_t offset; /* The byte sequence start, (0 based). */
};
However, this data is presently ignored.
Immediately following this structure are the bytes to write. The length of the entire packet is variable and handled at a higher level, therefore the number of bytes to write is the size of the command body less the sub-command (1 byte) and less the structure size (4 bytes).
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects the body to be empty.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
The FlashStartHash command expects to receive a body of:
struct StartTx
{
uint32_t length; /* Maximum image length is 4GiB */
};
This is used! But it's only checked to see that it's non-zero.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects to receive a body of:
struct ChunkHdr
{
uint32_t offset; /* The byte sequence start, (0 based). */
};
However, this data is presently ignored.
Immediately following this structure are the bytes to write. The length of the entire packet is variable and handled at a higher level, therefore the number of bytes to write is the size of the command body less the sub-command (1 byte) and less the structure size (4 bytes).
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects the body to be empty.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects the body to be empty.
This will start the verify_image systemd service.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects the body to be empty.
This command deletes any temporary files or flash image, hashes, etc.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects the body to be empty.
This command opens the verification result file and checks to see if it contains: "running", "success" or "failed". This then packs that as a 1 byte of result of:
enum VerifyCheckResponses
{
VerifyRunning = 0x00,
VerifySuccess = 0x01,
VerifyFailed = 0x02,
VerifyOther = 0x03,
};
This command expects the body to be empty.
Returns 16-bit version sequence (little endian), in the body, after the 3-byte OEM portion.
Should return type string "LPC" or "P2A" but does not yet. We need to add this into another command, such as FlashRegionSupportedType
returns 32-bit address (little endian) of either the BMC's memory buffer in BAR space (P2A bridge) or in LPC FW space (LPC bridge).
This command expects to receive:
struct ExtChunkHdr
{
uint32_t length; /* Length of the data queued (little endian). */
};
A design limitation of this is that it expects to be able to copy and write the data before the IPMI command times out, which should be completely possible.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command expects to receive:
struct ExtChunkHdr
{
uint32_t length; /* Length of the data queued (little endian). */
};
A design limitation of this is that it expects to be able to copy and write the data before the IPMI command times out, which should be completely possible.
On success it will return 1 byte of 0x00, in the body, after the 3-byte OEM portion.
This command maps a chunk (size specified by host) of the BMC memory into LPC space at a specified address. It expects to receive:
struct LpcRegion
{
uint32_t address; /* Host LPC address where the chunk is to be mapped. */
uint32_t length; /* Size of the chunk to be mapped. */
};
The command will return 1 byte in the response body with value:
After a success map to LPC space, the host can use FlashRequestRegion to read the LPC address of the chunk mapped, which should match that requested.