Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

zeroize: do not rely on volatile operations?

オープン
#1,269 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust
領域
security

調査の方向性

まず、zeroize の実装と zeroize/src/barrier.rs にある強化された black_box、および #1252 の optimization_barrier の変更を確認します。サポートされているすべての target で、単純な書き込みが volatile 書き込みを置き換えられるかを判断し、その後、実装とドキュメントを一貫して更新します。

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

説明

write_volatile docs explicitly state that:

Volatile operations are intended to act on I/O memory.

Using it on a non-volatile memory does not cause soundness issues, but it still can be considered a misuse of the function. It also can result in a very suboptimal codegen as noted in #743.

#1252 has introduced optimization_barrier which allows us to use simple writes optimizable by the compiler which are then "observed" by the barrier to prevent removal of the writes.

Unless we discover some practical issues with optimization_barrier, I think we can replace the volatile writes with simple writes. It would require changing promises made in the docs, but it should not matter in practice for downstream users.

As a potential compromise we could keep using volatile writes only on targets which do not have stable asm! macro and where optimization_barrier has to use the "hardened" black_box.

主要言語
Rust
スター
674
フォーク
170
平均マージ
1日 12時間
マージ済み PR（30日）
10

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

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

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

RustCrypto/utils のほかの issue

RustCrypto/utils の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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