OpenDevicePartnership / OpenDevicePartnership/patina

[Feature]: Investigate pointer provenance in the allocators

Open
#635 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

complexity:advanced state:needs-triage type:feature-request urgency:medium
Dominant language
Rust
Stars
544
Forks
54
Avg merge
1d 8h
Merged PRs (30d)
30

Description

Feature Overview

In support of running miri on portions of our codebase for static analysis, we need to improve our pointer provenance to better enable the compiler / miri to follow the flow of memory allocations as they are used throughout the codebase. Miri uses pointer provenance during static analysis to capture metadata such as:

  1. The size of the data the pointer points to, to make sure any writes do not go out of bounds
  2. The lifetime of the pointer, to make sure the data the pointer points at is not dropped
  3. Mutable aliasing

We also need to investigate the current provenance of the allocation pointers. Since we work in a no_std environment, it is most likely necessary to use with_exposed_provenance_mut to manually expose provenance metadata for later use, since it appears to the compiler that we are saying "This random physical address is now a pointer to an allocation". It may be possible to use strict provenance once exposed, but that needs to be investigated.

Solution Overview

Review the allocation code to either:

  1. Manage the allocations via a smart pointer such as NonNull<T> as they flow through the allocation flow, only converting them to usize immediately sending them across the C FFI boundary
  2. Manually expose the pointer providence as soon as the allocation is made, and update any conversions of the usize to a pointer to use the provenance aware functions such as with_addr or with_exposed_provenance_mut
Alternatives Considered

Keep it the same.

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

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

Trace the allocation code and follow allocation pointers through the C FFI boundary, noting every usize-to-pointer conversion. Compare carrying allocations as NonNull with exposing provenance and using with_addr or with_exposed_provenance_mut. Done means one strategy is applied consistently and the relevant code can be exercised under Miri.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
embedded-iot, operating-systems
Issue type
Feature
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.