[Feature request] Heap canary

Open
#58 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
operating-systems

Research direction

Start by reading the allocator's hole.rs around the reported overflow at line 311 and trace how Hole structures are created, modified, and checked. Define how optional magic-byte checks, corrupted addresses in panic messages, and whole-heap verification would integrate without production overhead. Done means the design and implementation cover these checks with a way to disable them.

Written by the indexing model from the issue text.

Description

help wanted

Recently I occurred a heap corruption bug in one of my real life projects:

Kernel panic - aborting: at /home/kazurin/.cargo/registry/src/rsproxy.cn-8f6827c7555bfaf8/linked_list_allocator-0.9.1/src/hole.rs:311: attempt to add with overflow

It took me long before I was able to discover the root cause, due to the complication of kernel debugging and the need to read the source code of various crates. It might be handy to have some simple heap canary mechanism (just like what Valgrind does) built into the allocator in such cases.

Features that I consider useful:

  • Ability to detect the corruption of heap control structures (namely the Holes) using some predefined magic bytes in the structure
  • Ability to reveal the corrupted structure's address in the panic message (for easier debugging)
  • Ability to verify the integrity of the whole heap at any time
  • The heap canary feature should be completely optional, in order not to cause preformance impact on production code

If such features are acceptable but not planned, perhaps I could do a PR in the future :)

Dominant language
Rust
Stars
242
Forks
56
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

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 rust-osdev/linked-list-allocator

All issues in rust-osdev/linked-list-allocator

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.