dropbox / dropbox/rust-alloc-no-stdlib

Soundness/documentation issue: CallocBackingStore::new is not safety documented and potentially unsound

オープン
#20 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Rust
スター
180
フォーク
21
PR マージ指標
30日以内にマージされた PR はありません

説明

The unsafe function CallocBackingStore::new does not have documentation for its safety invariants - and neither does the `define_allocator_memory_pool` macro calling it.
https://github.com/dropbox/rust-alloc-no-stdlib/blob/6032b6a9b20e03737135c55a0270ccffcc1438ef/src/lib.rs#L41

I believe the safety contract should mention that:
- the caller must guarantee that the allocator passed in can be safely called (including the corner-case of having a 0 argument for size), and returns buffers of the appropriate size.
- the correct relationship between `alloc` and `free` is upheld (free must be a valid function to free the memory allocated by `alloc`)
- computing `num_elements * sizeof(T)` must not overflow -- unless that is checked in the body of the function.

Moreover, using the macro with `malloc` is *always* unsound unless `T` is `MaybeUninit<_>`: `new` will end up creating a reference to a slice of uninitialized data, which is UB.
Even using the function with `calloc` might be unsound if `0` is not a valid bit pattern for `T`.
Similarly, when using a custom allocator, the bitpatterns returned by the custom allocator should be valid for `T`.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

src/lib.rs の CallocBackingStore::new と define_allocator_memory_pool マクロの周辺から始めてください。allocator のコールバックと slice がどのように使用されているかを確認し、issue で特定された安全性不変条件を、割り当てと解放の互換性および有効なビットパターンを含めて文書化してください。両方の unsafe エントリポイントが、呼び出し元に必要な保証を明確に示していれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
rust
領域
operating-systems
issue の種類
ドキュメント
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。