Project Cerberus

Firmware Update Specification

Author:
Bryan Kelly, Principal Firmware Engineering Manager, Microsoft
 Open Compute Project • Project Cerberus Firmware Update Specification

Revision History
Date Description
28/8/2017 Version 1.0

http://opencompute.org ii
 Open Compute Project • Project Cerberus Firmware Update Specification

© 2017 Microsoft Corporation.

As of November 1, 2017, the following persons or entities have made this Specification available under the Open Web
Foundation Final Specification Agreement (OWFa 1.0), which is available at http://www.openwebfoundation.org/legal/the-
owf-1-0-agreements/owfa-1-0

Microsoft Corporation.

You can review the signed copies of the Open Web Foundation Agreement Version 1.0 for this Specification at Project Olympus
License Agreements, which may also include additional parties to those listed above.

Your use of this Specification may be subject to other third party rights. THIS SPECIFICATION IS PROVIDED "AS IS." The
contributors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability,
non-infringement, fitness for a particular purpose, or title, related to the Specification. The entire risk as to implementing or
otherwise using the Specification is assumed by the Specification implementer and user. IN NO EVENT WILL ANY PARTY BE
LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS
GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE,
AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

CONTRIBUTORS AND LICENSORS OF THIS SPECIFICATION MAY HAVE MENTIONED CERTAIN TECHNOLOGIES THAT ARE MERELY
REFERENCED WITHIN THIS SPECIFICATION AND NOT LICENSED UNDER THE OWF CLA OR OWFa. THE FOLLOWING IS A LIST OF
MERELY REFERENCED TECHNOLOGY: INTELLIGENT PLATFORM MANAGEMENT INTERFACE (IPMI); I 2C IS A TRADEMARK AND
TECHNOLOGY OF NXP SEMICONDUCTORS ; EPYC IS A TRADEMARK AND TECHNOLOGY OF ADVANCED MICRO DEVICES INC.;
ASPEED AST 2400/2500 FAMILY PROCESSORS IS A TECHNOLOGY OF ASPEED TECHNOLOGY INC.; MOLEX NANOPITCH, NANO
PICOBLADE, AND MINI-FIT JR AND ASSOCIATED CONNECTORS ARE TRADEMARKS AND TECHNOLOGIES OF MOLEX LLC;
WINBOND IS A TRADEMARK OF WINBOND ELECTRONICS CORPORATION; NVLINK IS A TECHNOLOGY OF NVIDIA; INTEL XEON
SCALABLE PROCESSORS, INTEL QUICKASSIST TECHNOLOGY, INTEL HYPER-THREADING TECHNOLOGY, ENHANCED INTEL
SPEEDSTEP TECHNOLOGY, INTEL VIRTUALIZATION TECHNOLOGY, INTEL SERVER PLATFORM SERVICES, INTEL MANAGABILITY
ENGINE, AND INTEL TRUSTED EXECUTION TECHNOLOGY ARE TRADEMARKS AND TECHNOLOGIES OF INTEL CORPORATION;
SITARA ARM CORTEX-A9 PROCESSOR IS A TRADEMARK AND TECHNOLOGY OF TEXAS INSTRUMENTS; GUIDE PINS FROM
PENCOM; BATTERIES FROM PANASONIC. IMPLEMENTATION OF THESE TECHNOLOGIES MAY BE SUBJECT TO THEIR OWN LEGAL
TERMS.

http://opencompute.org iii
Contents
Summary ............................................................................................................................................................... 7

1 Firmware Image Storage ............................................................................................................................... 7

2 Firmware Update .......................................................................................................................................... 7

New Firmware Image ...................................................................................................................................7

Update Active Image ....................................................................................................................................7

Invalidating Signing Certificates ...................................................................................................................9

Firmware Update Process ............................................................................................................................9

3 Image Format and Verification .................................................................................................................... 12

Boot-Time Verification ...............................................................................................................................13

Image Update Verification .........................................................................................................................13

Application Launcher Format .....................................................................................................................14

Application Certificate Format ...................................................................................................................14

Main Application Format ...........................................................................................................................14

Update Verification ....................................................................................................................................15

4 Platform Firmware Manifest (PFM) Updates ................................................................................................. 2

Send PFM Update .........................................................................................................................................2

Update Active PFM .......................................................................................................................................3

PFM Image Format.......................................................................................................................................3

PFM Update Process ....................................................................................................................................4

iv August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Table of Figures
Figure 1 Send New Firmware Image Command Flow ............................................................................. 7
Figure 2 Image Update Command Flow ................................................................................................. 8
Figure 3 Firmware Update Process ....................................................................................................... 10
Figure 4 Update with Certificate Revocation ........................................................................................ 11
Figure 5 Firmware Image Format.......................................................................................................... 12
Figure 6 Boot-Time Verification Flow ................................................................................................... 13
Figure 7 Update Verification Flow ........................................................................................................ 13
Figure 8 Firmware Image Verification................................................................................................... 15
Figure 9 Application Launder Verification ............................................................................................ 16
Figure 10 Application Certificate Verification ......................................................................................... 17
Figure 11 Main Application Verification ................................................................................................... 1
Figure 12 Send New PFM Command Flow ................................................................................................ 2
Figure 13 Update PFM Command Flow .................................................................................................... 3
Figure 14 PFM Update Process ................................................................................................................. 4

http://opencompute.org v
Table of Tables
Table 1 Application Certificate Format .................................................................................................... 14
Table 2 Main Application Format ............................................................................................................ 14

vi August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Summary
Throughout this document, the term “Processor” refers to all Central Processing Unit (CPU), System On Chip (SOC),
Micro Control Unit (MCU), and Microprocessor architectures. The document details the procedure for updating the
Cerberus firmware image. It also covers the formatting and signing requirements for Cerberus firmware images.

1 Firmware Image Storage

The flash containing the Cerberus RoT firmware will be partitioned into three sections: Active, Recovery, and Staging.
The active partition contains the current firmware image being used by the processor. The recovery partition maintains
a known-good firmware image that can be used to restore the active image should something go wrong. The staging
partition is the storage location for new firmware that has not been applied yet.

2 Firmware Update
New Firmware Image
Before any update process can be started, the new firmware image must be sent to the device. The image will be sent
over the I2C bus after a trusted session has been established. The received image will be saved in the Staging area of
the RoT flash memory, and any image information previously stored in this area of flash will be lost.

Figure 1 Send New Firmware Image Command Flow

Update Active Image

Once a new firmware image has been completely stored in the Staging area of flash, the device can be directed to use
that image as the new running image. The update will only occur if the new image is verified to be a good. Verification

http://opencompute.org 7
of the new image is done using the same procedure as is used while booting the device. Once the image has been
verified, it will be copied into the Active partition.

The response to the update command will be immediate and will only indicate if the request to start the update process
has been processed correctly. To find out if the update is successful, the device must be polled for update status. The
update status command will always report the state of the last update attempt until the device is reset or a new update
request is received.

Once the update is complete, the RoT will start running the new image. Loading the new image will not be the same as
a complete reset of the device. The current context of the system will be retained, so any active sessions will remain
active. Also, boot-time initialization will not be re-run.

Figure 2 Image Update Command Flow

8 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Invalidating Signing Certificates

When it is necessary to revoke a signing certificate, a firmware image must be created and signed with the new
certificate. As part of the image metadata, it will indicate that the old certificate is no longer valid, and it will be revoked
as part of the update process. A side-effect of revoking a certificate is that the recovery image will no longer be valid if it
was signed with the revoked certificate. To ensure there is always an image that can be used for firmware recovery
operations, the image in the Recovery partition will also be updated when the recovery image has been invalidated due
to certificate revocation.

Firmware Update Process

The following diagrams describe the process executed by the RoT to update the firmware.

http://opencompute.org 9
 Start Update

Stop Running Active

Update Status:
Image and Load
Verifying Image
Flash Updater

Verify Firmware
Updater Update Status:
Image in Staging No
Running? Failed to Start
Area

Yes

Erase Active
Update Status: Is the Image Partition and Copy
No
Invalid Image Valid? Staging Image to
Active

Yes

Update Status: Active Update Update Status:

No
Backup Active Successful? Update Failed

Yes
Yes
Erase Active
Save Active Image to Partition and
a Backup Location Inspect New Image Restore Backup
for Certificate Image
Revocation

Update Status: Active Backup

No
Backup Failed Successful? Contains Update Status:
No
Revocation? Update Success

Yes
Yes
Update Status:
Updating Image

Certificate Restart the

Revocation Application Running
Process the Active Image

Store Application
Context in Flash

Load the Application

Context and Skip
Power-On
Initialization

Update Status:
No Context Saved?
State Backup Fail
Erase Previous
Context and Start
Application Services

Update Finished

Figure 3 Firmware Update Process

10 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification
Certificate
Revocation

Inspect Image in
Recovery Area for
Valid Certificate

Recovery Image Update Status:

Yes
Certificate Revoked? Backup Recovery

Save Recovery
Image to a Backup
Location

Update Status: Recovery Backup

Yes
No Update Recovery Successful?

No
Erase Recovery
Partition and Copy Update Status:
Staging Image to Recovery Backup Failed
Recovery

Update Status: Recovery Update

Yes
Revoke Certificate Successful?

No

Store Certificate
Update Status:
Revocation
Recovery Update Failed
Information

Erase Recovery
Partition and
Update Status: Certificate Restore Backup
No Image
Revocation Failed Revoked?

Yes

Update Status:
Update Success

Revocation
Complete

Figure 4 Update with Certificate Revocation

http://opencompute.org 11
3 Image Format and Verification
Both at boot and prior to running a firmware update, the validity of an image must be verified. In both cases, the same
firmware components will get validated. The firmware image contains three different sections of data to facilitate this
verification process. The first is the application launcher and firmware updater which will get validated using the
certificate programmed into the device. The second is the certificate that is used to validate the main application image.
This certificate is also validated using the root certificate in the device. The last part in the main application image, and
is signed with the application certificate. This certificate will be checked to see if it has been revoked, and if not, will be
used to validate the main application.

Application Launcher

Signed with root key and formatted to work with

the ROM bootloader

Application Certificate

Signed with the root key and read by the

application launcher

Main Application

Signed with a certificate contained in the

certificate list

Figure 5 Firmware Image Format

12 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Boot-Time Verification
While booting, the verification chain starts with the ROM bootloader verifying and running the application launcher.
The application loader verifies the application certificate, then uses this certificate to verify the main application. If the
main application is determined to be valid, it is executed.

1. Load and validate

with root key
Application Certificate

Load and
ROM Bootloader validate Application Launcher

Main Application
2. Validate with
application key

Figure 6 Boot-Time Verification Flow

Image Update Verification

When verifying an image for a firmware update, the main application must be able to verify all pieces of the new image.
The main application will parse each component of the firmware image to ensure that it is valid prior to starting the
update.

1. Extract application launcher

and validate with root key

2. Extract application certificate

and validate with root key
Main Application Staging Firmware Image

3. Extract main application and validate with

the extracted application certificate

Figure 7 Update Verification Flow

http://opencompute.org 13
 Application Launcher Format
The image format of the application launcher is determined by the ROM bootloader of the RoT.

Application Certificate Format

The application certificate will immediately follow the application launcher in the firmware image, and contains the
public keys for the certificates used for component validation. It also indicates which application certificates have been
revoked.

Length (Bytes) Value

1 Certificate ID
A certificate ID shall have at most one bit set. A certificate ID of 0 can never be
revoked and should only be used when the maximum number of revocations has
been exhausted.
1 Revocation Bit Mask
Each bit represents a certificate ID that has been revoked and should no longer be
considered valid.
256 RSA-2048 Application Public Key
256 RSA-2048 PFM Public Key
256 RSA-2048 Root Public Key
256 Certificate Signature
This is an RSA-2048 encrypted SHA-256 hash of all previous information using the
root key.
Table 1 Application Certificate Format

Main Application Format

The main application will immediately follow the application certificate in the firmware image. The image contains a
header that provides the signature of the application.

Length (Bytes) Value

4 Application Length
n Application Data
256 Signature
This is an RSA-2048 encrypted SHA-256 hash of all previous information using the
application key from the certificate.
Table 2 Main Application Format

14 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Update Verification
The following diagrams describe the process executed by the RoT to validate a firmware image prior to update.

Firmware Image
Verification

Extract Application
Launcher Image

Validate
Application
Launcher

Extract Application
Image Valid? Yes
Certificate

No

Validate
Application
Certificate

Extract Main
No Certificate Valid? Yes
Application Image

Validate Main
Application

No Image Valid?

Yes

Image Not Valid Image Valid

Figure 8 Firmware Image Verification

http://opencompute.org 15
 Application
Launcher
Verification

Parse ROM
Bootloader Header

Generate SHA-256
Hash of Root Public
Key in Header

Hash Matches
No
OTP Hash?

Yes

Generate SHA-256
Hash of Application
Image

Decrypt Image
Signature with Root
Public Key

Signature Hash
Matches Calculated No
Hash?

Yes

Application Image Application Image

Valid Not Valid

Figure 9 Application Launder Verification

16 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification
Application
Certificate
Verification

Generate SHA-256
Hash of Root Public
Key in Certificate

Hash Matches
No
OTP Hash?

Yes

Generate SHA-256
Hash of Certificate
Data

Decrypt Certificate
Signature with Root
Public Key in
Certificate

Signature Hash
Matches Calculated No
Hash?

Yes

Bitwise AND
Certificate ID and
Hardware
Revocation BIts

Result is 0? No

Yes

Certificate Valid Certificate Not Valid

Figure 10 Application Certificate Verification

http://opencompute.org 17
 Open Compute Project • Project Cerberus Firmware Update Specification

Main Application
Verification

Read Length of
Application Data

Generate SHA-256
Hash of Application
Header and Data

Decrypt Application
Signature with
Application Public
Key

Signature Hash
Matches Calculated No
Hash?

Yes

Application Not
Application Valid
Valid

Figure 11 Main Application Verification

http://opencompute.org 1
4 Platform Firmware Manifest (PFM) Updates
The Cerberus RoT firmware contains a manifest detailing the firmware allowed for the other devices in
the platform. As new firmware becomes available for these components, the Platform Firmware
Manifest (PFM) needs to be updated, but it is not desirable to upgrade the entire Cerberus firmware to
achieve this update.

Send PFM Update

The process for sending a new PFM to the Cerberus RoT is similar to the process of sending a new
firmware image. After a secure session is established over I2C, the updated PFM can be transmitted to
the RoT. This updated PFM will be stored in a staging area, much like firmware images, before it gets
applied as the active PFM.

Session Establishment
...

Figure 12 Send New PFM Command Flow

2 August 28, 2017

 Open Compute Project • Project Cerberus Firmware Update Specification

Update Active PFM

After the new PFM has been transmitted to the RoT, Cerberus can be directed to apply that PFM as the
active PFM to use for component validation. The PFM must be signed with the PFM key from the
Application Certificate. This signature will be used to validate the PFM prior replacing the active PFM.

Just like firmware updates, the command to update the PFM will return immediately and only report if
the command was received correctly. In order to find out the PFM update status, the Cerberus RoT
must be queried.

Send New PFM

...

Figure 13 Update PFM Command Flow

PFM Image Format

The main application will immediately follow the application certificate in the firmware image. The
image contains a header that provides the signature of the application.

Length (Bytes) Value

4 PFM Length
n PFM Data
256 Signature
This is an RSA-2048 encrypted SHA-256 hash of all previous information using the
PFM key from the certificate.

http://opencompute.org 3
 PFM Update Process
The follow diagram describes the process taken by the Cerberus RoT to update the PFM.

Start PFM Update

Update Status:
Verifying PFM

Generate SHA-256
Hash of PFM Header
and Data

Decrypt PFM
Signature with PFM
Public Key

Signature Hash
Update Status: Update Status:
Matches Calculated Yes
Backup PFM Updating PFM
Hash?

Erase Active PFM

Save Active PFM to a
and Copy New PFM
Backup Location
to Active
Yes

No

PFM Backup PFM Update Update Status:

Yes
Successful? Successful? Update Success

No No

Update Status: Update Status: Update Status:

Apply New PFM in
PFM Invalid Backup Failed Update Failed
Running Image

Restore PFM Backup

Copy

PFM Update
Finished

Figure 14 PFM Update Process

4 August 28, 2017