wolfBoot/tools/uart-flash-server
Daniele Lacamera 524397df70 F-5675: fix signed-overflow UB from uint8_t<<24 in serve_update version assembly
Shifting a uint8_t (int-promoted) left by 24 is undefined behaviour per C11
6.5.7p4 when the byte value is >= 0x80. Cast the MSB operand to uint32_t at
both sites (CMD_APP_VER line 391, CMD_HDR_VER line 412).

Note: the report's endian-mismatch claim is incorrect. CMD_APP_VER senders
(app_nrf52.c, app_stm32f4.c, app_stm32wb.c) all transmit version bytes
MSB-first; CMD_HDR_VER is sent LSB-first by uart_send_current_version. The
two decode expressions are intentionally asymmetric and both reconstruct the
correct version value.
2026-06-11 18:53:49 +02:00
..
Makefile F-4339: widen uart-flash-server bounds checks to 64-bit to stop uint32_t wrap 2026-06-10 21:01:16 +02:00
README.md External, emulated non-volatile memory over UART 2020-04-03 14:27:42 +02:00
test_overflow.c F-4339: widen uart-flash-server bounds checks to 64-bit to stop uint32_t wrap 2026-06-10 21:01:16 +02:00
ufserver.c F-5675: fix signed-overflow UB from uint8_t<<24 in serve_update version assembly 2026-06-11 18:53:49 +02:00

README.md

UART interface for secure local updates

This directory contains a daemon that can be used on a host machine to emulate a remote non-volatile memory on the target, using a UART channel.

wolfBoot interface

The Uart Flash driver uses the same API as other external flash memories. The target can be connected through a serial line to a host that can provide update images by emulating the UPDATE partition on the target.

wolfBoot must be compiled with the option UART_FLASH=1. The back-end drivers to access the UART interfaces are in the uart drivers directory on this repository.

ufserver usage

The 'uart flash server' (ufserver) requires two arguments:

  • The path to the signed firmware update image (e.g. ../../../test-app/image_v2_signed.bin)
  • The serial port connected to the target (e.g. /dev/ttyS0)

When a new image is processed for the first time, an update flag is set automatically to indicate that the update is available.

The bootloader will use the image file as its update+swap partition, so the file will be modified by wolfboot during and after an update.

Authentication

The daemon does not perform any signature verification, nor it checks the integrity of the firmware image passed as command line argument. wolfBoot is still in charge of verifying integrity and authenticity of the received update, and more in general, of every image before it is staged to boot.

Swap and fail-safe operations

When installing an update using this mechanism, wolfBoot will erase the content of the file on the filesystem and will overwrite its content with a copy of the older version. As long as the daemon is running, wolfBoot will still be able to roll-back to a previous version if booting the update fails.