oxidecomputer / oxidecomputer/hubris

Post-linking operations on a Hubris image can create over-sized images

Open
#1,678 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

This is an issue more for the build and sign flow as opposed to Hubris itself.

A companion bug should be filed on permission-slip to ensure that additional image checks are made prior to creating a signature.

Hubris images that link at close to the maximum flash size (262144. or 0x40000 bytes) can be pushed over that
threshold when trailing data is added, such as a signature block.

A default Hubris build for the LPC55S69 when used as a Root of Trust (RoT) includes signing with a well-known
private key named "Bartholomew" or "Bart".

To mimic what should happen in the production signing flow, the "Bart" signing should not complete if an image
would exceed the available flash size on the part.

In the log below, the faux-mgs tool knows the size of the image but does not know, prior to installation, that it exceeds the available flash space.

The RoT's update_server knows the limit and fails the update appropriately with UpdateError::OutOfBounds but only after the alternate flash bank has been erased and partially programmed. This erase/re-programming reduces system resilience by removing a what was probably a viable backup copy of Hubris and contributes to flash wear.

Detecting errors earlier makes them cheaper. So, there should be multiple checks that prevent invalid images from being installed. Starting at image creation,
going through signing/release, deployment, installation tooling, and then safeguards at the device's own installation
flow and boot-time checking.

voidstar:~/.../src/hubris/update-stage0,rot-carrier$ faux-mgs-dev --log-level=DEBUG --json=pretty update rot 1 $HUMILITY_ARCHIVE_B
Mar 23 02:01:32.631 INFO creating SP handle on interface enp65s0f0, component: faux-mgs
Mar 23 02:01:32.631 DEBG attempting initial SP discovery, discovery_addr: [fe80::c1d:62ff:fecd:cc62]:11111, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:32.633 INFO generated update ID, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, component: faux-mgs
Mar 23 02:01:32.633 DEBG refreshed scope ID for SP interface, discovery_addr: [fe80::c1d:62ff:fecd:cc62%2]:11111, interface: enp65s0f0, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:32.634 INFO initial discovery complete, addr: [fe80::c1d:62ff:fecd:cc62%2]:11111, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:32.678 INFO starting update, total_size: 262152, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, component: rot, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:32.684 INFO update in progress, total_size: 262152, bytes_received: 0, component: faux-mgs
Mar 23 02:01:32.684 INFO update preparation complete, update_id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:32.685 DEBG sending update chunk, offset: 0, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
...
Mar 23 02:01:40.857 INFO update in progress, total_size: 262152, bytes_received: 244500, component: faux-mgs
...
Mar 23 02:01:41.355 DEBG sending update chunk, offset: 259170, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:41.390 DEBG sending update chunk, offset: 260148, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:41.423 DEBG sending update chunk, offset: 261126, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:41.441 DEBG sending update chunk, offset: 262104, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
Mar 23 02:01:41.467 ERRO update failed, error: Error response from SP: update: out of bounds, id: 1fe0bfce-c707-4a0d-8c5d-83b6bc5169d6, interface: enp65s0f0, component: faux-mgs
{
  "enp65s0f0": {
    "Err": "updating rot slot 1 to /home/stoltz/Oxide/src/hubris/update-stage0/target/rot-carrier/dist/b/build-rot-carrier-image-b.zip failed: update failed (error Update(OutOfBounds))"
  }
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the faux-mgs-dev reproduction in the issue and trace how the image's total_size reaches installation. Compare the signing flow involving the "Bart" key with permission-slip and the RoT update_server, which reports UpdateError::OutOfBounds. Done should prevent oversized images from progressing into erase/program operations and cover the relevant creation, signing, deployment, installation, and boot-time checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, embedded-iot, release
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.