[Feature]: Enforce the MMIO single-owner boundary with lint and visibility rules

Open
  • Is something wrong?
#491 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
40/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
embedded-iot

Research direction

Start in firmware/runtime/src/memory/mmio.rs to see how MmioRegion::new() and range() are defined, then search for their callers in firmware/runtime/src/memory/registry.rs and firmware/prototyper/src/driver/device/. Check whether range() is used outside the crate before narrowing it to pub(crate). Add the #![deny(unsafe_code)] guard to the device subtree and confirm the workspace still builds. Settle the ownership-lifetime wording with a maintainer before writing code.

Written by the indexing model from the issue text.

Description

C-enhancement help wanted

Problem Statement

Runtime's MmioRegion centralizes volatile register access, but the single-owner boundary currently relies partly on review discipline:

  • MmioRegion::range() publicly exposes the authorized physical range.
  • The driver device/ subtree does not have a module-level deny or forbid(unsafe_code) guard.
  • Ownership transfer out of the initialization context is not represented in the type system.

There is no known bypass in the current drivers. The request is to make future bypasses harder to introduce accidentally.

Motivation and Use Cases

The bounded MMIO handle is most effective when register access cannot silently move back to raw pointers in a new driver. Compile-time lint and narrower visibility would preserve the existing access pattern without adding runtime cost.

Proposed Solution

  • Add #![deny(unsafe_code)], or forbid where appropriate, to the driver device subtree.
  • Reduce MmioRegion::range() to pub(crate) unless an external consumer requires it.
  • Keep MmioRegion::new() crate-private and document the intended ownership lifetime when a region leaves platform initialization.
  • Add a compile-time check or code comment explaining where raw MMIO access is permitted.

Alternatives Considered

A fully type-encoded ownership lifetime would provide stronger guarantees, but it is a larger API change. Keeping the current review-only approach is simpler and leaves the boundary easier to weaken during driver development.

References

  • firmware/runtime/src/memory/mmio.rs
  • firmware/runtime/src/memory/registry.rs
  • firmware/prototyper/src/driver/device/
Dominant language
Rust
Stars
1.3k
Forks
184
Avg merge
2d 23h
Merged PRs (30d)
29

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No 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.

More from rustsbi/rustsbi

All issues in rustsbi/rustsbi

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.