InfiniTimeOrg / InfiniTimeOrg/InfiniTime

SPI EasyDMA UB

Open
#2,228 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug maintenance
Dominant language
C
Stars
3.4k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

I was looking into https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/components/ble/DfuService.cpp#L390 and it turns out that the EasyDMA engine cannot read from flash! - See https://docs.nordicsemi.com/bundle/ps_nrf52832/page/easydma.html

Further reading: https://github.com/nrf-rs/nrf-hal/issues/37

There is potential UB across the codebase here - any SPI writes using constant buffers may be stored in flash and therefore be invalid. In particular, all of the display writes may be invalid if the compiler is moving constant arrays to flash (and not copying them to the stack first). Oddly all of the display commands seem to be fine (they clearly work!), while the DFU magic clearly isn't.

I don't know the exact method the compiler uses to decide the storage location. Does anyone know it?
It's certainly affected by constexpr etc.
I might try to analyse the compiler output, but I don't have the tooling to load the binary set up, and it wouldn't be as good as understanding the actual allocation algorithm.

I've got a few ideas here:

  1. Add a check that hard crashes if a flash pointer gets passed into Spi::Write to prevent this from happening in the future
  2. Introduce some kind of blocking write. A lot of these writes are small, but we still don't want to store this data in static RAM. So instead we can load them onto the stack, and then block until the write is complete (won't be waiting long as they are small). We need to wait as data in the stack frame can be overwritten as soon as the function returns by future function's stack frame.
  3. An alternative to (2) would be allocating write buffers on the heap and then the SPI controller freeing them when done. In practice InfiniTime pretty much never runs out of heap, and when it does it usually hangs pretty quickly anyway (LVGL dies).

It looks like the nrf-hal team implemented (1), but only support blocking writes currently.

I'm sure I've missed other good options too, so I'd love any input on this.

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 src/components/ble/DfuService.cpp around line 390 and trace the SPI writes through Spi::Write. Read the Nordic EasyDMA documentation and the linked nrf-hal discussion to verify which buffers are valid during transfers. Done requires selecting and implementing a safe handling strategy for constant or flash-resident write buffers across the affected code paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
embedded-iot
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.