OpenDevicePartnership / OpenDevicePartnership/patina
[Feature]: Investigate pointer provenance in the allocators
Nobody has claimed this yet.
- 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:
- The size of the data the pointer points to, to make sure any writes do not go out of bounds
- The lifetime of the pointer, to make sure the data the pointer points at is not dropped
- 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:
- Manage the allocations via a smart pointer such as
NonNull<T>as they flow through the allocation flow, only converting them tousizeimmediately sending them across the C FFI boundary - 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_addror 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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