High Assurance Rust

本書は、正当な根拠をもって信頼できる高性能なソフトウェアを構築するための入門書です。 つまり、コードの機能性とセキュリティに対する確信を裏付ける十分なデータを持つということです。 信頼性は、高保証ソフトウェアの特徴です。

保証を中核となる概念として、本書では、ソフトウェア開発における2つの基本的でありながら、しばしば近づきにくいトピック、すなわちシステムプログラミングと低レベルソフトウェアセキュリティに、ハンズオンかつプロジェクトベースのアプローチで取り組みます。

Rustを学びます。Rustは、速度と正確性を重視する、モダンなマルチパラダイム言語です。 ほとんどのプログラミング書は、小規模で非現実的なプログラムを十数個示すことで新しい言語を教えます。 本書はそうではありません。

Rustの標準ライブラリにある順序付きマップとセットの実装に代わる、機能を完備した実装を設計し、書き、検証します。 主要な動的コレクションの1つを、イディオマティックなAPIごとに再実装することで、Rust言語を深く理解できるようになります。

標準版とは異なり、私たちの実装は次のようになります。

• 最大限に安全。 考えられるすべての実行に対して、Rustの最も強力なメモリ安全性保証を維持します。

  • コンパイラが証明できない性質をテストするために、差分ファジングや*演繹的検証**を含む高度なプログラム解析技術を学びます。

• 極めて移植性が高い。 あらゆるオペレーティングシステム上で、あるいはオペレーティングシステムなしでも（例: 「ベアメタル」）実行できます。

  • 私たちのライブラリは堅牢化されたコンポーネントです。より大きなコードベースに統合するため、Rust関数をCやPythonを含む他の言語から呼び出せるように、CFFIバインディングを追加します。

• 高可用。 そうでなければクラッシュにつながる可能性のあるケースを処理するための、失敗可能なAPIを提供します。

  • 例: メモリ不足（OOM）エラー - 事前に割り当てられたメモリがすべて使い果たされた場合。

実践的ソフトウェア保証における最先端

本書で書くコードを検証するために、最先端のオープンソースのソフトウェア保証ツールを使用します。 これらのツールの一部は成熟しており、商用業界で使用されています。

• rustc（モダンなコンパイラ）
• libFuzzer（ファジングテストフレームワーク）
• rr（「タイムトラベル」デバッガ）
• qemu（システム全体のエミュレータ）

その他のツールは実験的で、活発に研究されています。 完全な一覧は付録で確認できます。

視覚的には、本書は以下のトピックを扱います（開発速度と形式的厳密性のトレードオフでおおまかに対比しています）。 心配はいりません。それぞれについて明確な説明と背景を提供します。

開発速度に重きが置かれている点に注目してください。 私たちが関心を持っているのは、長期的に見て、高品質なコードをより速く出荷し、セキュリティと信頼性の問題に対するパッチ適用に費やす時間を減らすことを可能にする、軽量なプロセスです。 現実世界のコードに適用できる技術です。 今日から使えます。

他のRustの本とは異なり、本書で学ぶのは言語だけではありません。 最先端の領域で、ソフトウェアセキュリティについて推論する方法を学びます。 攻撃者のように考える方法。 そして、攻撃に耐性のあるコードを書く方法。 そのメンタルモデルは、主にどのプログラミング言語を使っているかに関係なく価値があります。

本書を支援するスポンサー

本書の開発（調査、執筆、コーディング）は、以下の寛大な支援によって可能になっています。

2022 Project Grants Programの第1期助成によるものです。 採択されたプロジェクトの完全な一覧はこちらで確認できます。グローバルなRustコミュニティ内で進行している刺激的な取り組みの数々をぜひご覧ください！

あなたは、ミッションクリティカルなアプリケーションを支えるデータ構造ライブラリを構築する必要があります。 それは、ほぼあらゆるデバイス上で動作し、現場で何年にもわたってエラーなく稼働し、攻撃者に制御された入力に耐えなければなりません。 パッチは存在せず、失敗は許されません。 あなたのコードは生き残らなければなりません。 強く出荷せよ。

* == 変更される可能性があります！本書は制作途中です。完成時や物理版の提供開始時に通知を受け取りたい場合は、こちらから登録してください。

よくある質問（FAQ）

0. 簡潔に言うと、この本は何を目指していますか？

• セキュアで堅牢なシステムの開発について、わかりやすく、かつ原則に基づいた入門を提供すること。「最先端」と「短期的に実用可能」の重なり合う領域、つまり主に本番環境レベルのツールと手法を扱いつつ、最先端の研究プロジェクトもいくつか取り上げます。すべてオープンソースです。

• 経験豊富な開発者が新しい言語を学ぶと同時に、コンピューターサイエンスとコンピューターアーキテクチャの基本的なトピックをより深く掘り下げられるよう支援すること。

1. この本は誰向けですか？

上の図に示した要素の何らかの組み合わせに関心がある人なら誰でも対象です。

• Rustプログラミング言語
• ソフトウェアセキュリティ
• データ構造（特に自己平衡木）
• システムプログラミング

ただし、一般的なコーディングにはすでに十分慣れていることを前提としています。 熟練したソフトウェアエンジニアでなくてもかまいませんが、3,000行以上のプログラムを書いてデバッグした経験があることを想定しています。 再帰をすでに理解しており、コマンドラインツールの使い方を知っている必要があります。

また、この本は、あなたが深く技術的なトピックに興味を持っていることも前提としています。 メモリ管理やパフォーマンス最適化のようなものです。 物事が実際にどのように作られているのかという細部です。 かなり深いところまで踏み込みます。

2. では、これは上級者向けの本ですか？

プログラム解析の研究、バイナリエクスプロイト開発、自己平衡木のような「高度な」題材を避けることはしません。 この本の一部は難しいかもしれませんが、すべてのトピックをできるだけ理解しやすく、魅力的にするよう努めます。

付録には「基礎」と記された短いセクションが含まれています。 これらは、異なる背景を持つ読者に対応するため、主要な概念への任意の入門を提供します。 章が特定の知識を期待または推奨している場合、それはこれらの付録セクションのいずれかで扱われています。

さらに、この本に登場する引用ブロックのかなりの部分は、周囲のテキストに説明的な文脈を与えることを明確に意図しています。 大まかには次の形式に従います。

ここに概念Xに関する質問

概念Xと関連キーワードについての簡単な説明。 網羅的ではありませんが、正しい方向への手がかりになることを願っています。

C言語は短いスニペットで時折使用しますが、あなた自身がCを書いたことがまったくないものとして扱います。 Rustの事前経験は必要ありません。

数学については明確に説明し、複雑なトピックを視覚的に説明するために図を使用します。

3. これは単なるデータ構造の本ですか？

いいえ。 ただし、強力なマップ/セットライブラリを組み立てる足場として、特定のデータ構造（「スケープゴート木」と呼ばれます）を使用します。 データ構造というレンズを通して学びます。データ構造は、抽象理論の厳密さと実用的な実装の技巧を組み合わせるものです。 そして、Rustの最も新しい概念の習熟へと進みます。

4. この本の「ハンズオン」な点は何ですか？

各章を通して、コードを書き、最先端のツールを使います。

前半が終わるころには、データ構造ライブラリにリモートコマンドを送信して、ライブでテストするようになります。 さらに注目すべき点は、それが組み込みシステムの仮想的な複製の中で「ベアメタル」で実行されることです。 ハードウェアを購入する必要がないということ以上に、それが実際に何を意味するのかを説明します！

この本の内容は、実世界のライブラリの実装に基づいています。 さらに重要なのは、Rustの標準ライブラリで広く使われているコレクションとAPI互換の代替を構築することです。 これは「おもちゃ」の例ではありません。

5. どのような「ハッカー」（ここでは低レベルセキュリティの意味）スキルを学べますか？

セキュアなシステムを構築するために、システムを攻撃できる能力が必須というわけではありません。 しかし、攻撃者のように考え、同じツールの一部を適用できれば、確かにより容易になります。

防御的（いわゆる「ブルーチーム」）スキルと攻撃的（いわゆる「レッドチーム」）スキルの幅を紹介しますが、前者に重点を置きます。

• ブルーチームのスキル（重点）:

  • Rustでのセキュアコーディング
  • 軽量な形式的検証
  • 安全な外部関数バインディング

• レッドチームのスキル（補足）:

  • 現代的なバイナリエクスプロイトの基礎
  • リバース動的デバッグ
  • カバレッジガイド付きファジングによるバグ発見

6. 学んだことを仕事に適用できますか？

C Foreign Function Interface（CFFI）バインディングを扱います。あなたのAPIはPython3とC99の両方のコードから呼び出せるようになります。 これは、高速でセキュアなRustコンポーネントを既存の仕事のコードベースに統合するための実践的なスキルです。

加えて、試すことになる静的検証ツールと動的テストツールはすべて無料でオープンソースです。 Rustだけでなく、複数の言語で書かれた実行ファイルを解析できるものもあります。 ツール一覧の完全版は付録にあります。

たとえ本番環境でRustを実行する機会がまったくなくても、システムセキュリティのスキルを得られます。 それらはさまざまな文脈で価値を持つ可能性があります。

7. Rustを安全性が重視される領域で使用できますか？

可能性はあります。領域によります！ Rustツールチェーンは、たとえばSPARK/Adaほど広く認証されているわけではまだありません。 しかし、安全性が重視される製品でのRust採用は活発に進展しています。 最近の例（網羅的ではありません）:

• Ferroceneプロジェクトは公式Rustコンパイラのダウンストリームであり、自動車（現在はISO 26262による）および産業（現在はIEC 61508）環境で「品質管理され、使用に適格とされた」ものです。

• Infineon Technologiesのようなハードウェアベンダーも、同様に自社プラットフォームを対象とするRustツールチェーンの提供を開始しつつあります。

• AdaCoreのようなソフトウェアベンダーは、安全性が重視される用途に特化したRustツールを現在提供しています。

この本は、業界に関係なく、一般にセキュアで堅牢なソフトウェアを構築することについて扱います。 Rustを取り巻く規制環境が発展するにつれて、ここで扱うトピックをより多くの業界分野に適用できるようになるでしょう。 ほとんどの業界にとって、Rust は本番環境で使える状態にあります。 今この時点で。 この言語は現在、多くのミッションクリティカルな場面で使用されています。 Web スケールのインフラストラクチャ、金融サービス、コンシューマー製品などです。

免責事項: 本書の著者の 1 人は、現在、安全性が重要なシステムにおける Rust の使用に関するガイドラインを作成している SAE International のタスクフォースに、ボランティアとして参加しています。

8. この本は無料ですか？

もちろんです！ ペイウォールも、義務も、ゲートキーピングもありません。 本書全体は https://highassurance.rs で一般公開されています。

ただし、まだ作業中です。 長期的な目標は、基礎的なトピックについて、コミュニティのすべての人に高品質なリソースを提供することです。 バランスの取れた本を作るには、時間と反復が必要です（フィードバックをお待ちしています）。

本書に価値を感じた場合は、以下の方法でこのプロジェクトを支援できます。

• 本書の GitHub リポジトリにスターを付ける: こちらです。スターを付けることで、開発者の間でこのプロジェクトの可視性が高まります。

• 本書全体で参照している他の書籍のいずれかを購入する: 脚注は出典を引用するために使用されます。 その出典が、私たちが愛し大切にしている技術教科書である場合、脚注には [PERSONAL FAVORITE] というタグで区別された Amazon アフィリエイトリンクが含まれます。 これらのリンクは控えめに使用されており、本当に必読だと感じている本にのみ使われます。 完全な一覧は付録にあります。 リンクを使用して購入すると、本書と、当然ながら購入した本の両方を支援することになります。

• 物理版の順番待ちリストに登録する: 将来のある時点で、High Assurance Rust は完成し、磨き上げられ、物理的な印刷に値するものになるでしょう。 ハードコピーに興味がある場合は、通知を受け取るためにこちらから登録してください。

継続的な教育を重視する有力なセキュリティスタートアップまたはエンタープライズですか？ 現在の開発者や将来開発者を目指す人々にリーチするために、本書のランディングページにロゴを掲載したいですか？ もしそうであれば、Sponsor Call for Proposals (CFP) ページをご覧ください。

9. 他に知っておくべきことはありますか？

本書を実現するために、多大な努力が注がれました。 私たちが書くのを楽しんだのと同じくらい、皆さんにも読むことを楽しんでいただければ幸いです。 一緒にハックしましょう！

* == 変更される可能性があります。まだ書かれていません！本書は作業中です。

本書に関わりましょう！

フィードバック、質問、Issue、またはPRを送信する

全般的なフィードバックがありますか？ あるいは、どうしても聞きたい質問があるかもしれません。

本書は執筆中であり、皆さんからのご意見が重要です。 ぜひご意見をお聞かせください。以下までメールをお送りください：

contact@highassurance.rs

事実関係または文法上の誤りを見つけましたか？

GitHubでIssueまたはPull Request (PR)を送信してください。 プロジェクトのCONTRIBUTING.mdを参照してください。

リポジトリにスターを付ける

GitHubリポジトリにスターを付けることで、開発者の間でこのプロジェクトの認知度を高める手助けができます。 皆さんのご支援に深く感謝します。

本書：

scapegoat Crate：

友人にすすめる

友人にリンクを送ることを検討してみてください。友人は本書全体を無料で読むことができます！

章内の小見出しをクリックすると、ブラウザーのアドレスバーにその箇所を示すURLが表示されます。

High Assurance Rustを引用する

本書はアクセシビリティを念頭に設計されていますが、高度なトピックを掘り下げ、関連する研究を文脈づけていきます。 ページ下部の脚注では一次資料を引用しています。

ご自身の著作で本書を直接引用したい場合は、以下のBibTeXまたは同様の形式を使用してください：

@misc{high_assurance_rust,
    title={High Assurance Rust: Developing Secure and Robust Software},
    url={https://highassurance.rs},
    howpublished = "\url{https://highassurance.rs}",
    author={Ballo, Tiemoko and Ballo, Moumine and James, Alex},
    year={2022}
}

このプロジェクトを支援するその他の方法

FAQの質問8はこちらを参照してください。

よろしくお願いします！

スポンサー向け提案募集（CFP）

本書の読者は、ソフトウェア関連のキャリアやセキュリティ製品に関心を持っている可能性が高いでしょう。 これは、2つのステークホルダーに関わる発見の問題です。

1. 参加したくなるような魅力的なチームを探しているエンジニア。

2. セキュリティに精通したエンジニアの手に高品質なツールを届けたい企業。

本書の主な目的は、無償の教育です。 しかし、両者に利益があるなら、これらのステークホルダーをつなげることもぜひ実現したいと考えています。

お願いしたいこと

• 貴社が2つの基準を満たしていること。

  1. 技術職（ソフトウェア開発、セキュリティエンジニアリング、テクニカルライティング、プロダクトマネジメントなど）を有する雇用主であること

  2. セキュリティ関連の製品（SaaS、ハードウェア、レポートなど）または専門サービス（コンサルティング、トレーニング、研究開発など）を提供していること

• 本書の開発を支援するための、1回限りの寄付。

  • 貴社の現在のマーケティング予算と比べれば、おそらくごく少額です。

  • 継続教育のために無償で利用できるリソースを支援することになります。

• 執筆セクションについての簡潔な提案。

  • 以下をご覧ください。

提供できること

• 本書のランディングページに、貴社のロゴをスポンサーとして掲載し、貴社が選択する2つのリンク（採用ページ、製品ページなど）を設定します。

  • ロゴはスポンサー開始日の順（早いものから新しいものへ）に表示されます。

  • このドメインが存続する限りロゴを掲載します（10年以上を保証）。

  • どのような理由であっても、いつでもロゴやリンクの削除を依頼できます（例: 本書の今後の章が貴社の価値観や品質基準を満たさない場合）。

• 本書の末尾にある専用のスポンサー章での執筆セクション。

  • 製品利用のチュートリアル、チーム文化に関する記事など。

  • 最大3,500語まで、貴社（そのトピックの専門家）が執筆します。

  • トラッキングやアナリティクスは許可されません（昔ながらの雑誌広告のように、読者のプライバシーを尊重します）。読者情報を収集または共有することはできません。

    • 本書のリポジトリのスター数は、すでに可視性を示す透明かつ自発的な指標として機能しています。

スポンサーになることをご希望の場合は、簡潔な提案（プレーンテキストまたはPDFを推奨）を以下までお送りください。

contact@highassurance.rs

ぜひご連絡ください！

当方は、いかなる理由であっても（例: ブランドの評判、提案トピックなど）、スポンサーシップのご依頼を丁重にお断りする権利を留保します。読者に対して誠実でなければなりません。

ダウンロード

この本は、Webページとして閲覧することをおすすめします。 オフラインで閲覧する場合は、リポジトリをクローンして完全なローカルコピーを取得できます（ローカルで配信するには make read）。 あるいは、以下を利用できます。

• EPUB

  • 最終エクスポート: 10/8/23
  • SHA-3-256: 23e158a622087b88c906b269c8a0523ae81d17b2e01a89ccb4ea81e4342c5e2e

• PDF（いつの日か公開予定）

ハッシュは openssl dgst -sha3-256 <file_name> で検証できます。

お楽しみください！

変更履歴

注: この本は制作途中であり、その内容（現在または将来）は変更される可能性があります。 誤りを見つけた場合は、ご連絡ください。

• v0.4.3-alpha:

  • 新セクション: 14.4 戦術的信頼 (1/2)
  • コミュニティから投稿された修正。技術的正確性の向上に貢献してくれた pixelshot91 に特別な感謝を
  • mdbook を更新（v0.4.35 -> v0.4.51）。複数のレンダリング更新を含む

• v0.4.2-alpha:

  • 内部ツールの更新（メトリクス、リンター）
  • 計算されたページ数と図の数を含むランディング/README.md バッジ
  • EPUB ダウンロードを更新
  • それぞれのオープンソースリリースを踏まえ、Ferrocene と FLS への言及を更新（やった！）

• v0.4.1-alpha:

  • 新セクション: 4.2 保証の観点: スタック安全性
  • 新セクション: 16.10 理論: 手続き間 CFG
  • 4.0、4.1、および 4.4 の改訂。
  • 多数の新規および改訂された 4.X の図。

• v0.4.0-alpha:

  • 新セクション: 4.1. ソフトウェアの観点: CPU からスタックへ
  • 新セクション: 4.3. 攻撃者の観点: 安全性を破る (1/2)
  • 新セクション: 4.4. 攻撃者の観点: 統一理論 (2/2)

• v0.3.2:

  • 2022 Project Grants Program を通じた Rust Foundation のスポンサーシップ！
  • 1.1、2.10 に新しい図と議論。
  • 2.2 と 2.7 に新しい補足説明。
  • CODE_OF_CONDUCT.md を追加。
  • EPUB ダウンロードに SHA-3-256 ハッシュとタイムスタンプが含まれるようになりました。

• v0.3.1:

  • コミュニティ貢献者一覧を開始し、CONTRIBUTING.md を追加。
  • コミュニティからのフィードバックに基づく複数の修正と改善。
  • 徹底的なレビューと深い技術的洞察を提供してくれた jam1garner に感謝。
  • EPUB ダウンロードを追加。

• v0.3.0:

  • Hello, world! :)
  • 初期コンテンツ（第 1、2、3 章、および付録の大部分）の公開リリース。

• v0.0.0:

  • オープンソースの scapegoat ライブラリは、この本の中核プロジェクトが実現可能であることを示しています。
  • Rust の主要な強みであるメモリ安全性とベアメタル移植性を最大限に活かします。

日付は、速度ではなく品質に集中するため、意図的に省略しています。コードについては例外で、かなり高速です（スタックに格納されるアリーナ、再帰なし）。

ライセンス

本書のテキスト

本書のすべてのテキストは、クリエイティブ・コモンズ 表示-非営利-改変禁止 4.0 国際 (CC BY-NC-ND 4.0) ライセンスの下でライセンスされています。

本書のコード

本書のすべてのコード（およびその基になっているオープンソースライブラリ）は、MITライセンスの下でライセンスされています。

MIT License

Copyright (c) 2022 Tiemoko Ballo, Moumine Ballo, Alex James

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

はじめに

システムプログラミング――あなたがこれから足を踏み入れようとしている世界――において、私たちは現状に甘んじるようになってしまいました。 もしかすると、加担してさえいるのかもしれません。

私たちは顧客に対して信頼性が高く安全なソフトウェアを約束してきましたが、そこには暗黙の但し書きがありました。性能を犠牲にしてはならない、というものです。 そして、最速の言語は伝統的にメモリ安全ではありませんでした。 それらを使用することで、私たちは一般的な機能要件と、最も基本的な防御姿勢の両方を積極的に危険にさらしています。

• 信頼性: メモリ安全性エラーは、予測不能なクラッシュ（例: 「セグメンテーションフォルト」）、再現不能なエラー（例: 「データ競合」）、そして最終的なサービス停止（例: 「メモリリーク」）を引き起こします。

• セキュリティ: 同じメモリエラーによって、攻撃者が機密データを読み取れるようになったり（例: 「秘密情報を盗む」）、被害を受けたプログラムの権限でほぼ任意のコマンドを実行できるようになったりする可能性があります（例: 「完全制御」）。

プログラムがクラッシュしたり、不正な出力を生成したりすることは一つの問題です。 あなたのマシンがボットネットに参加することは、また別の問題です¹。 メモリ安全でないプログラムは、これら両方の結果を同時にもたらす危険があります。

こうした途方もないリスクは、ガベージコレクションや重量級ランタイムを使用する、ほとんどの現代的な「アプリケーション言語」（Python、Java、Go などを想像してください）では、大部分が軽減されています²。 しかし、安全性が重要なシステム、高性能な分散インフラストラクチャ、さまざまな種類のファームウェアなど、C と C++ に依存し続けている重要な分野があります³。

時代とともに自らを再発明し、世界で最も重要なソフトウェアの多くを支えてきたにもかかわらず、これら 2 つの伝統的な「システム言語」は、依然として最悪級のセキュリティ脆弱性（例: Heartbleed⁴、Stagefright⁵、EternalBlue⁶、Dirty Pipe⁷ など）の主要な供給源であり続けています。 メモリ破損の脅威は衰えていません。

これが、数十年にわたって後方互換性にコミットしてきた代償です。 私たちは、自分たちがその肩の上に立つ巨人たちをけなそうとしているわけではありません。

しかし、その肩はひどく重い荷を背負っています。 2012 年の重要な研究論文⁸は、「Systematization of Knowledge: Eternal War in Memory」という適切な題名のもと、30 年にわたる C と C++ のメモリ保護スキームの失敗を記録しました。 新しい防御策はことごとく、新しい回避技術によって打ち破られてきました。

時を進めて 2019 年。 Microsoft の調査⁹は、同社製品における 2004 年から 2018 年までのすべてのセキュリティ問題について、次のように述べています。

毎年セキュリティ更新プログラムによって対処される脆弱性の約 70% は、依然としてメモリ安全性の問題である。

この割合には、市場をリードする巨大企業である Microsoft におけるエンジニアの経験やソフトウェア品質プロセスが反映されています。 もしあなたがすでに C または C++ プログラマーであるなら、これは受け入れがたい真実です。 それは理解できます。

• C は革命でした。プロセッサ間で移植可能な「高水準」プログラムを世界にもたらしました¹⁰。そして今日、それはほぼすべてのデバイスのかなり深い層で動いています。

• C++ の強力な抽象化は、Web ブラウザー、グラフィックスエンジン、データベースなど、驚くべき規模の高性能なシステムを可能にしています。私たちがなくてはならないソフトウェアです。

しかし、進化は遅れすぎているのかもしれません。 Google による 2022 年の分析¹¹では、「実際に悪用されているものとして検出および開示された」これまで未知だった（例: 「ゼロデイ」）エクスプロイトについて、次のことがわかりました。

その年［2021 年］に実際に悪用された 58 件の 0-day のうち、39 件、つまり 67% はメモリ破損脆弱性だった。 メモリ破損脆弱性は、過去数十年にわたりソフトウェアを攻撃する標準的な手段であり続けており、攻撃者が今なお成功を収めている方法でもある。

調査対象となったエクスプロイトの一部は、ジャーナリスト、政治家、活動家、マイノリティ集団を標的にするために実際に使用されていました¹¹。 メモリ破損は理論上の問題ではありません。 それは差し迫った深刻な問題であり、最悪の場合には具体的な人的被害を伴います。

もし私が、常に本当に慎重で、いつでも気を抜かないとしたらどうでしょうか？

現代的な C 系言語のベストプラクティスは、メモリ脆弱性の可能性を低減できます。 しかし、それらを排除できるとは思えません。 そして Rust のコンパイル時エラーやランタイムチェックとは異なり、ベストプラクティスをスケールさせることは困難です。

数十年分のデータは、開発者の勤勉さと広範なテストではメモリ安全性の問題を確実に解決できないことを示しています。 根本原因への対処を真剣に検討すべき時です。

もう現状に甘んじる必要はありません

Rust は比較的新しいシステム言語として、伝統的に C/C++ の領域であったものをサポートします。 それは、コンパイラによって強制される「所有権」¹²という、別のパラダイム群を提供します。

もし Rust を一度も試したことがないなら、ほぼ全知だが狭い範囲に集中する完璧主義者とペアプログラミングしているところを想像してみてください。 所有権の概念を実装するコンパイラコンポーネントである借用チェッカーは、ときにそのように感じられます。

それに伴う学習曲線と引き換えに、私たちはメモリ安全性の保証を得ます。 つまり、多くの場合、常にではないにせよ、すべてのメモリエラーが存在しないことを確実に証明できるということです。

Rust は 2010 年に Mozilla によって発表され¹³、2021 年時点では独立した非営利団体によって主導されており¹⁴、過去 40 年のシステムプログラミングにおける最も差し迫った単一のセキュリティ問題、すなわちメモリ安全性を大部分解決します。

商業的に実用可能なプログラミング言語として、メモリ安全性とベアメタルの速度を同時に提供する、おそらく初めての言語です。

それは単なる意見でしょうか？

それは大きな勢いを得つつある意見です。 社会的受容と市場圧力のあるしきい値を超えれば、退屈なほど当たり前の立場にさえなるかもしれません。 Rust を本番環境で使用しているユーザーの一部から、同様の見解を紹介します:¹⁵

Amazon:¹⁶

…AWS では、Firecracker VMM のような重要インフラストラクチャを Rust で構築することがますます増えています。なぜなら、Rust の標準機能により、Amazon の高いセキュリティ基準に到達するために必要な時間と労力を削減できる一方で、C や C++ と同様のランタイム性能を引き続き提供できるからです。

Google:¹⁷

私たちは、Rust が［Linux］カーネルを実装するための実用的な言語として C に加わる準備が整ったと感じています。Rust は、コアカーネルとうまく共存し、その性能特性を維持しながら、特権コードにおける潜在的なバグやセキュリティ脆弱性の数を減らす助けになります。

Microsoft:¹⁸

［Rust は］この［メモリ安全性］問題に正面から取り組むための、業界にとって最良の機会です。 さらに、Rust は米国政府のセキュリティガイダンスの最前線にも登場し始めています。 このセクションが最初に公開された時点（2022年3月）以降、さまざまな政府機関が、メモリ安全性という深刻な社会的問題に対する解決策として Rust を明示的に挙げるようになりました。

国家安全保障局（NSA）:¹⁹

ソフトウェア解析ツールはメモリ管理の問題の多くの事例を検出でき、動作環境のオプションも一定の保護を提供できますが、メモリ安全なソフトウェア言語が提供する本質的な保護は、ほとんどのメモリ管理問題を防止または軽減できます。NSA は、可能な場合はメモリ安全な言語を使用することを推奨します。

…メモリ安全な言語の例には、C#、Go、Java、Ruby、Rust、Swift があります。

サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）:²⁰

ほかのどの産業であれば、市場が、製品のユーザーにとってこれほどよく理解されており深刻な危険を何十年も容認するでしょうか?

…数年前まで欠けていたのは、C/C++ の速度と組み込みのメモリ安全性保証を備えた言語です。2006年、Mozilla のソフトウェアエンジニアが Rust という新しいプログラミング言語の開発を始めました。Rust バージョン 1.0 は 2015年に正式に発表されました。

米国国立標準技術研究所（NIST）:²¹

安全性や品質をプログラムに「テストで後付け」することはできません。最初から設計に組み込まれていなければなりません。より安全またはよりセキュアな言語や言語サブセットで実装することを選択すれば、弱点のクラス全体を完全に回避できます。

…Rust には所有権モデルがあり、ガベージコレクターを必要とせずに、コンパイル時にメモリ安全性とスレッド安全性の両方を保証します。これにより、ユーザーは多くのバグクラスを排除しながら、高性能なコードを書くことができます。Rust には unsafe モードがありますが、その使用は明示的であり、許可されるアクションの範囲も狭く限定されています。

それは Rust プログラムが侵害されないという意味ですか?

まったく違います。 メモリ破損は、バグクラスの 1 つにすぎません。 それは特に厄介で、高価値のエクスプロイトチェーンの一部であることが多いものですが²²、ほかのバグクラスも存在します。

多くの、もしそうでなくてもほとんどのセキュリティ問題は、言語に依存しません（例: 設定ミス²³、コマンドインジェクション²⁴、ハードコードされたシークレット²⁵ など）。 また、メモリ安全な言語が独自の問題を持ち込むこともまれにあります（例: 信頼できない入力のインタープリター評価、別名「eval インジェクション」）。 どのプログラミング言語も、あらゆる攻撃に対してあなたのコードを完全にセキュアにしてくれるわけではありません。

さらに、Rust にはあまり知られていない厄介な秘密があります。 先に触れておきましょう。Rust の unsafe キーワードを使う必要がある場合があります。これは、特定のコードブロック内で潜在的にメモリ安全でない振る舞いを許可します。 その意図は、コンパイラーが自動的に検証できないアクションの安全性を、人間が慎重にレビューすることです。 そして、それはコードベース全体ではなく、いくつかの重要な箇所に限られます。

この本のコアプロジェクトでは、unsafe をまったく使う必要はありません! Rust の保証を最大限に活用するために、問題を慣用的な方法で捉え直す方法を学びます。 これは、この言語から具体的なセキュリティ上の価値を引き出すための重要なスキルです。

しかし、状況認識と将来の取り組みのために、以下を扱います。

• unsafe の使用法と影響を詳しく取り上げます。
• Rust アプリケーションの安全性を監査するためのツールを学びます。
• ケーススタディとして、Rust ソフトウェアにおける実世界の脆弱性をいくつかレビューします。
• 安全でない言語から Rust コードを呼び出すための Foreign Function Interface（FFI）バインディングを構築します。

Rust はシステムセキュリティにおける途方もない飛躍ですが、万能薬ではありません。

Rust は C や C++ を置き換えることになりますか?

C と C++ は、現代世界で最も広く使われているソフトウェアの一部を支えています。 膨大な数の C ファミリーのコードベースが何十年も前から存在しており、今後さらに何十年も進み続けるでしょう。 重要な問題に対して、長年の実績に裏付けられた解決策を提供しているからです。

プロのシステムプログラマーは、3 つすべての言語の経験から恩恵を受けられます。 C ファミリーがすぐになくなることはありません。 そして Rust は既存の C/C++ コードと統合できます。 ランタイムオーバーヘッドなしでです。

これは Rust の本ですが、C の小さなスニペットをいくつか目にすることになります。 通常それらは、すべての C プログラマーが認識しておくべき微妙な「未定義動作」の問題を示すものです。

また、Foreign Function Interface（CFFI）を介して、あなたが構築するライブラリを C から呼び出すためのバインディングも書きます。 これは、別の言語で書かれた既存のコードベースに新しい Rust コンポーネントを統合するための前提条件です。

curl の興味深い事例

curl²⁶ は、URL を使ってデータを転送するためのユーティリティで、1998年以降広く普及しており、C で書かれています。 このツールは非常に広く依存されているため、そのセキュリティは私たちが「インターネット」と見なすものの多くに影響します²⁷。

2020年時点で、curl はセキュリティを強化するために、HTTP と TLS の Rust バックエンド（CFFI 経由で呼び出される）を統合しています²⁷。 メモリ安全な Rust コードは、既存の C コードとシームレスに統合されます。 すべてが 1 つのコンパイル済みバイナリであり、言語間相互運用性によるパフォーマンスペナルティはありません。

平均的なエンドユーザーには違いが分からないとしても（そしてそれは良いことです!）、curl は今や、より安全で信頼性の高いプログラムになっています²⁸。

新しい言語を採用することは本当に労力に見合いますか?

あなたはおそらく、自分が選んだ言語/ツールチェーン/エコシステムに相当な経験時間を投資してきたでしょう。 知識の多くが移転可能だとしても、Rust はその労力に見合うのでしょうか?

すべてのプロジェクトに当てはまるわけではありません。 Rust は、性能、信頼性、セキュリティのすべてがミッションクリティカルな要件である場合に魅力的な選択肢です。 このように相反しがちな基準が交わるところでは、正当化可能な確信に到達するための障壁は、従来ばかばかしいほど高いものでした。 ここで言っているのは「形式手法」です。機械支援による証明、モデル検査、シンボリック実行などです。 これらのアプローチは価値がある一方で、産業界での大規模な採用には障害があります。

現在、Rust の保証は、これらの検証アプローチが総体として提供するものの小さなサブセットです。 しかし Rust は、それに伴う実用性上の落とし穴の多くも回避しています。

Rust のコンパイラーは、重要な性質の特定の集合をほぼ自動的に証明し²⁹、私たちが迅速に出荷できるようにします。 表面的には、低レイテンシ性能を犠牲にすることなくメモリ安全性を得られます。 さらに深く見ると、私たちの優位性は、実際には商用開発のペースで行える原理に基づいた検証にあります。 実世界のコードの速度で、[一部の] 証明を得られるのです。

検証はおもちゃのプログラムだけのものではないのですか?

形式的な裏付けのある保証のほとんどは研究用プロトタイプに限定されています。大規模でマルチスレッドのコードベースには単にスケールしません。 そのため、形式手法は実務のソフトウェアエンジニアの間で評判がよくありません。難しすぎるうえに、価値が十分ではないのです。

対照的に、Rust コンパイラーはもともと、Firefox のブラウザーエンジンのコンポーネントを堅牢化するために設計されました¹³。これは数百万行規模で高度に並列な商用コードベースです。

さて、どれほど有益になり得るツールであっても、採用と影響を得るには使いやすくなければなりません。 当初の学習曲線はあるものの、Rustは過去7年連続で「最も愛されている」プログラミング言語に選ばれました。 StackOverflowの年次開発者調査³⁰では、2022年に73,000件を超える回答が寄せられました³¹。

わかりました。では、Rustを学べますか？

あなたが別の国へ移住し、新しい言語を話せるようになることを選んだと想像してみてください。 簡単ではないでしょうが、それだけの価値があるかもしれません。 Rustにおける高保証プログラミングへの私たちの第一歩も同様に、困難ではあるものの、やりがいのあるものになるでしょう。

新しいことを学ぶことの素晴らしさは、誰にでもできるという点にあります。 少しの時間と適切なリソースが必要ですが、十分に長く続ければ、物事が腑に落ち始めます。 本書は、Rustの高い学習曲線をすばやく手なずける手助けをします。そうすることで、私たち全員が共同で信頼できるシステムソフトウェアを構築できるようになります。

学習成果

• 本書が何を扱い、なぜ扱うのかを理解する
• 本書が技能習得のドレイファスモデルのどこに位置づけられるかを理解する
• Rustを書き始められるように開発環境をセットアップする

1. You Can’t Spell Trust Without Rust。Aria Desires（2015）。Rust標準ライブラリのBTree作者の1人によるこの修士論文は、このボットネットの類推の出典であり、本書全体への影響源でもあります。 ↩

2. ここで「大部分は」としているのは注意書きです。Pythonにもデータ競合はあり得ますし、Goにもセグメンテーションフォールトはあり得ます、などです。しかし、ガベージコレクションを備えた言語は、CやC++と同じ強力な悪用プリミティブを攻撃者に与えるわけではありません（詳細は第4章で述べます）。そのため、同じリスクを伴うわけではありません。 ↩

3. CとC++は、それぞれのかつての姿との共通点と同じくらい、互いの共通点も少ない、と主張するのは正しいでしょう。C++11³²はC++20³³とはほとんど似ていません。ざっと読む代わりに言うと、公式のC++言語標準は、合計で1,308ページ³²から1,823ページ³³へと、515ページ、ほぼ40%増加しました。 ↩

4. Embedded System Security with Rust: Case Study of Heartbleed。Jens Getreu（2016）。 ↩

5. Stagefright: Scary Code in the Heart of Android。Joshua Drake（2015） ↩

6. EternalBlue Exploit: What It Is And How It Works。SentinelOne（2019）。 ↩

7. The Dirty Pipe Vulnerability。Max Kellerman（2022）。 ↩

8. SoK: Eternal War in Memory。Laszlo Szekeres、Mathias Payer、Tao Wei、Dawn Song（2012）。 ↩

9. Trends, challenges, and strategic shifts in the software vulnerability mitigation landscape。Mat Miller（2019） ↩

10. Episode 53 - C Level, Part I。Sean Haas（2021）。このポッドキャストで説明されているように、Cはアセンブリへコンパイルされる最初の言語ではありませんでした。広く採用されるようになった、そのアイデアの実用的な変種です。 ↩

11. The More You Know, The More You Know You Don’t Know。Maddie Stone、Google Project Zero（2022）。 ↩ ↩2

12. 所有権はまったく新しいものではなく、類似の概念は研究用言語によって先駆的に取り組まれていました。密接に関連する概念であるライフタイムは、C++コミュニティに以前から存在していました³⁴。しかし、Rustの新しい所有権システムは、コンパイル時にライフタイム規則を強制します。C++では、注意しないとライフタイムに関する仮定が実行時に破られる可能性があります。その結果、バグや脆弱性が生じる可能性があります。Rustは、特定のC++のベストプラクティスをコンパイラそのものの中で結晶化したものだと主張する人もいます。 ↩

13. Project Servo, Technology from the past come to save the future from itself。Graydon Hoare（2010）。 ↩ ↩2

14. Hello World!。Ashley Williams（2021）。 ↩

15. Production Users。The Rust Team（アクセス日: 2022年）。 ↩

16. Why AWS loves Rust, and how we’d like to help。Matt Asay、Official AWS Open Source Blog（2020）。 ↩

17. Rust in the Linux kernel。Wedson Almeida Filho、Official Google Security Blog（2021）。 ↩

18. Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming。Joab Jackson（2020）。 ↩

19. Software Memory Safety。NSA（2022）。 ↩

20. The Urgent Need for Memory Safety in Software Products。Bob Lord、CISA（2023）。 ↩

21. Safer Languages。NIST（2023）。 ↩

22. Zoom RCE from Pwn2Own 2021。Thijs Alkemade、Daan Keupe（2021）。 ↩

23. A05:2021 – Security Misconfiguration。OWASP（2021）。 ↩

24. Apache Log4j Vulnerability Guidance。CISA（2021）。 ↩

25. CVE-2022-1162。National Vulnerability Database（2022）。 ↩

26. curl。Daniel Stenberg（2021）。 ↩

27. Memory Safe ‘curl’ for a More Secure Internet。Internet Security Research Group（2020）。 ↩ ↩2

28. 本稿執筆時点では、Rust対応ビルドのcurlはデフォルト構成ではありません。curlをビルドして配布する人々（たとえばOSディストリビューションのメンテナー）が、サポートするプラットフォームやユーザーに適したビルド構成を選ぶことになります。注目に値する妥当な取り決めです！ ↩

29. Computer Scientist proves safety claims of the programming language Rust。Saarland University（2021）。Rustの形式検証は、現在の成果と継続中の作業の両方を含む研究課題であることに注意してください。 ↩

30. Technology: Most loved, dreaded, and wanted。StackOverflow（2022）。 ↩

31. Methodology: Participants。StackOverflow（2022）。 ↩

32. [最終] ワーキングドラフト、プログラミング言語 C++ 標準。文書番号:N3337 (2012)。文書番号 3337 - 1337 にとても近い！惜しい機会を逃しました。 ↩ ↩2

33. [最終] ワーキングドラフト、プログラミング言語 C++ 標準。文書番号:N4861 (2020)。 ↩ ↩2

34. Lifetime。cppreference.com (2022年閲覧)。 ↩

なぜこの本なのか？

Rust の勢いには、いくつもの要因が連なっています。 無料で高品質な学習リソース¹が利用できることは、間違いなくその 1 つです。 優れた公式テキストである The Rust Programming Language² も含まれます。

では、なぜまた別の Rust の本が必要なのでしょうか？ 実のところ、本書は 本当の意味では Rust についての本ではありません。ただし、読者がこの言語を学ぶ手助けをすることは主要な目標です。 本書は、根本的に重要でありながら、気後れするほど難しいトピックへの入口です。それは、システムプログラミングと低レベルセキュリティです。

より具体的には、システムに関するトピックとして、組み込みに適したデータ構造と、言語間の相互運用性を扱います。 セキュリティに関するトピックとしては、静的検証、動的なバグ発見、バイナリ悪用を扱います。

これらのトピックを取り上げることが、今後の皆さんの役に立つことを願っています。 あるいは、単に「物事がどのように動いているのかを理解したい」という欲求を満たすだけでもかまいません。

健全な懐疑心についての注記

本書は、技術的に正確で、データに基づき、実用的であることを目指しています。 しかし、本書には意見も含まれています。 ここで示される立場は、著者たちの信念と経験を反映しています。

あらゆる主張、とりわけセキュリティに関する主張は、批判的な視点を通して評価されるべきです。 これは本書に限ったことではなく、一般に当てはまります。 偏りのない情報などというものは存在しません。

健全な懐疑心という姿勢を培い、維持することをお勧めします。 それは、どのようなソフトウェアセキュリティの文脈でも大きな見返りをもたらします。

事実誤認を見つけた場合は、お知らせください。

なぜシステムプログラミングについて学ぶのか？

3 人のエンジニアに「システムプログラム」が何をするものか尋ねたら、おそらく 3 つの異なる答えが返ってくるでしょう。 これは、さまざまな業界やユースケースにまたがる幅広い分野です。

• 「システムプログラムは分散されており、低レイテンシで意思決定を行い、合意プロトコルを介してネットワーク上で協調するものです」と、1 人目のエンジニアは言うかもしれません。

  • 例：分散データベースやフォールトトレラントサービス。

• 「違います」と、2 人目は口を挟むかもしれません。「システムプログラムは、ユーザー空間アプリケーションから見たハードウェアの姿を管理し、物理リソースの利用をスケジューリングして促進するものです」。

  • 例：オペレーティングシステムやデバイスドライバー。

• 3 人目は不満そうな顔をして、「低消費電力デバイス上でセンサーデータを収集する緊密なフィードバックループはどうでしょうか？ それはリソースをまったく共有していません！」と付け加えるかもしれません。

  • 例：マイクロコントローラーや制御システム向けのファームウェア。

3 つの答えはすべて正しいものです。 共通する筋（しゃれのつもりです³）は、システムプログラムの目標がハードウェアリソースの制約と結びついているという点です。 それらは低レベルに位置します。 特殊用途のデバイスでは、それが存在する唯一のレベルです。

より一般的には、それはユーザーが直接やり取りする高レベルプログラムの基盤です。 リソースの効率的な利用、つまり性能は重要です。少しの低速化でも増幅され、それに依存するすべての高レベルプログラムに影響を及ぼします。

システムプログラムを素早く見分けるために、次のような質問をすることができます（経験則はすべてそうであるように、これは近似です）。

• そのプログラムが応答性に優れていると感じる必要があるのは誰ですか？

  • 人間： それはシステムプログラムではありません。人間の時間に制約されています（ミリ秒単位で測られます。これは私たちにとって実感できる最小の単位です）。

  • 別のプログラム： それはシステムプログラムです。マシンの時間に制約されています（CPU サイクル単位で測られます。現代のプロセッサは毎ミリ秒に数百万サイクルを実行します）。

高レベルアプリケーションを書くことにしか関心がないとしても、低レベルアプリケーションについて少し（最後のしゃれです、約束します）理解しておくことは役に立ちます。 自分の下にあるレイヤーとより効果的にやり取りでき、スタック内の自分のレベルにあるボトルネックに対しても、同じ性能志向の考え方を適用できます。それがどのレベルであってもです。

レベル別の言語

Rust プログラミング言語はシステムソフトウェア専用に使われるわけではありませんが、それが強みであることは確かです。 Rust は、スクリプト言語（Python、Ruby、Lua など）やガベージコレクション付き言語（Java、Go、C# など）では動作できないスタックのレベルで実行できます。 常に存在するこれらの低レベルでは、メモリ安全ではないシステム言語（C と C++）が何十年にもわたって独占してきました。

より安全なシステムプログラミングを提供する言語はどれか？

プログラミング言語は、突き詰めれば単なる道具です。 言語の選択は熱のこもった議論を引き起こすかもしれませんが、結局のところ重要なのは、その仕事に最適な道具を選ぶことです。

利用可能な選択肢を認識していなければ、客観的ではいられません。 Rust の旅を始める前に、より安全なシステムプログラミングの代替となる 2 つの選択肢、Zig と Ada について簡単に触れておくべきでしょう。 Rust と同様に、どちらもネイティブにコンパイルされ、ガベージコレクションを使用せず、C 系言語に対する安全性の利点があります。 3 つの言語はいずれも、現代的な低レベルプログラミングに同程度に適しています。 3 つとも、特定の文脈では優れた選択肢です。

詳細な比較の代わりに、ミッション・クリティカルシステムおよびセーフティ・クリティカルシステムの開発における成熟度という観点から、3 つの選択肢を対比してみましょう。 ミッション・クリティカルシステムとは、本番環境で稼働しており、セキュリティや信頼性の障害が事業にとって高くつくものだと仮定します。 また、セーフティ・クリティカルシステムは物理現象を駆動するため、セキュリティや信頼性の障害が人命、財産、または環境を危険にさらす可能性があるものだと仮定します。

• Rust（成熟度：中）- Rust は 2015 年に 1.0 に到達し、ミッション・クリティカルな本番環境でのユーザーや用途が非常に豊富にあります⁴。Rust を安全クリティカル領域に持ち込むための現在の取り組みには、Ferrous Systems と AdaCore の協業⁵、AUTOSAR Working Group⁶、SAE International Task Force⁷、そして形式検証ツールに関する継続的な研究開発⁸が含まれます。本稿執筆時点で、Ferrocene⁹ Rust ツールチェーンは、自動車（ISO 26262 ASIL-D）および産業（IEC 61508 SiL4）ユースケース向けの認定を完了しつつあります。

• Ada（成熟度：高）- Ada の 1.0 仕様である MIL-STD-1815-A¹⁰ は 1983 年にリリースされました。商用サポートされているコンパイラとランタイムライブラリは、DO-178B/C（航空）、ISO 26262（自動車）、IEC 61508（産業）、ECSS-Q-ST-80C（宇宙）などの規格での使用に対して、すでに認定されています¹¹。Ada のサブセットである SPARK は、成熟した演繹的検証機能を提供します¹²。SPARK は、Rust の型システムに一部触発され、ヒープメモリ検証において近年進歩を遂げています¹³。

どのプログラミング言語であれ、それを学ぶことは開発者として成長するための素晴らしい方法です。 健全なコミュニティを持つ新しい言語は、時間の経過とともに独自のニッチを見つけ、その革新を洗練させていくかもしれません。 確立された言語は、現時点でより豊富なツールやライブラリエコシステムを提供できます。 利用可能な選択肢が複数あることは、開発者にとっても、最終的には顧客にとっても良いことです。

私たちは、Rust が今日の多くのプロジェクトにとって卓越したツールであり、明日のさらに多くのプロジェクトにとっても有力な選択肢になると信じています。

設計による安全性

Zig、Rust、Ada は、次のうち 1 つ以上に対してさまざまな戦略を採用しています。

• 安全機能を型システムに直接組み込む（コンパイル時の強制）

• デフォルトのランタイム安全チェックを無効にするには明示的なオプトアウトを要求する（ランタイム検出）

安全性を言語の中核設計に組み込むことで、欠陥除去を確実にスケールさせやすくなります。 オプトインのベストプラクティスを教育したり、サードパーティのエラーチェッカーを使用したりする場合と比べてです。

その一方で、既存プロジェクトが新しい言語ツールチェーンを学習して採用するコストは高くなる可能性があります。 また、新しいプロジェクトで安全でない言語を選ぶことに妥当な理由がある場合もあります。 ツール選定は、状況に大きく依存する問題です。

なぜデータ構造ライブラリを構築するのか？

ホワイトボードでのコーディング面接が嫌な後味を残したのかもしれません。 大学のデータ構造の授業が、いまひとつ腑に落ちなかったのかもしれません。 あるいは独学だからこそ、このトピックが学術的で、ほとんど関係のないものに感じられるのかもしれません。 結局のところ、ライブラリはすでに書かれています。自分で二分探索木を実装することが一度もなくても、長く実りあるソフトウェアのキャリアを築くことはできます。

しかし、データ構造には特別なものがあります。 データ構造は、計算機科学理論の数学的厳密さと、効率的な実装という実践上の制約を組み合わせます。 それは、抽象と具象が交差する場所で何が可能なのかを垣間見せてくれる、まれな存在です。 いわば、数学というタイヤがコードという路面と接する場所です。

現代のプログラミング言語の標準ライブラリには、データ構造 API、つまり「コレクション」が含まれています。 これらの API は、その言語で書かれたほぼすべてのプログラムで使われます。 1 つのデータ構造実装がこれほど広く使われる可能性があるため、パフォーマンスは極めて重要です。 そのため、現実世界のデータ構造は通常、速度のために Rust や C のようなコンパイル型言語で実装されます。 これには、Python のようなインタプリタ型言語の標準ライブラリに含まれるものも含まれます¹⁴！

データ構造ライブラリを構築することは、複雑な機能要件の集合を取り、それをコンパクトで正しいコードへ変換することを伴います。 それは、戦略的なレベル（全体のアルゴリズム）と戦術的なレベル（使用している言語における、insert、get、remove などの個々の構造操作の仕組み）の両方で、目標を達成する道筋を示してくれます。

一般に応用できる問題解決スキルと、言語固有の開発スキルの両方を学ぶことになります。

コンパイル型 vs. インタプリタ型:

コンパイラ（C の gcc や Rust の rustc など）は、ソースコードをネイティブバイナリ、つまり CPU が直接実行する命令で満たされた実行可能ファイルへ変換します。その結果、特定の CPU 命令セットアーキテクチャ（ISA - 例：x86、ARM、RISC-V など）向けに構築された、非常に高速なプログラムになります。

インタプリタは、ソースコードを一度にひとかたまりずつ実行します。インタプリタプログラムは、構文木をたどることであなたのプログラムを実行します。これは実行が遅くなることを意味しますが、インタプリタ（おそらくそれ自体がネイティブバイナリ）が対応している限り、どの CPU に対しても移植性があります。

実際には、その境界線が常に完全に明確なわけではありません。Python は実際にはソースをバイトコード（インタプリタが理解する命令）へ変換します。これは一種のコンパイルです。

覚えておくべきことはこれだけです。システムソフトウェアは、効率が最優先事項であるため、ネイティブにコンパイルされなければなりません（CPU 命令に変換されなければなりません）！

Rust ではデータ構造は特に難しいのでは？

Rust のメモリ安全性の保証は、システムソフトウェアのセキュリティにおける大きな進化です。 業界での採用が広がり、ライブラリエコシステムが活況を呈している Rust は、システムプログラミングとセキュアコーディングの両方にふさわしい代表格です。

しかし一部のデータ構造は、コンパイラが安全性固有の性質を検査する方法のために、Rust で書くのが悪名高いほど難しい¹⁵ことで知られています。 これは、ある要素が別の要素に到達する方法を知っており、その逆も成り立つような構造（たとえば「循環参照」を持つもの）で特に当てはまります。 このためにあまりにも苛立ち、素早く膝を突き上げてキーボードを真っ二つに折り、Rust を完全に諦めてしまう開発者もいます！

だからこそ、あなたは高度なデータ構造から Rust の旅を始めることになります。 それは、Rust の最も難しい概念に正面から取り組むようあなたを押し出します。 厄介なデータ構造の Rust 実装がまだ存在しない場合でも、問題を Rust らしい方法で捉え直し、自分で実装するために必要なスキルを身につけることになります。

その能力こそが、Rust で成功するための足場です。最終的な目標が何であれ。 メモリがどのように機能し、Rust がそれをどのように管理するのかについてメンタルモデルを構築できれば、安全なシステムソフトウェアを出荷する道を順調に進んでいることになります。

セキュリティ以外では、なぜ Rust なのか？

Rust はパフォーマンスを最大化できるからです。

ムーアの法則¹⁶は限界に達し、物理法則は命令スループットとクロック速度に上限を設けました。 ボトルネックが実際にプログラムの CPU 時間である（たとえばネットワークレイテンシやディスク I/O の制限ではない）と仮定すると、パフォーマンスを改善する方法は通常 2 つあります。

1. 問題に対して、より優れたアルゴリズムが存在するなら、それを実装する。
2. 遅い処理を複数のコアに並列化する。 Rust のメモリ推論は、[多くの場合より現実的な] 後者の選択肢に役立ちます。コンパイラが信頼性の高い並行性を保証してくれるからです。 これは、アルゴリズムのロジックを自動的に並列化するという意味ではありません（それは依然として難題です）。また、すべての競合状態を防ぐという意味でもありません（たとえば、コンパイラはデッドロックについて推論できません）。

しかし、すべての「データ競合」（起こり得る競合状態の重要なサブセット）から解放されることは意味します。 それらは、「タイミング」（組合せ的なスレッドのインターリーブ）に関する前提の微妙な誤りによって引き起こされる、一見ランダムな状態破壊です。

並行プログラミングは、従来、正しく行うのが非常に困難でした。 性能上の利点を得るには、問題を捉え直すことと、予測不能な挙動をデバッグすることの両方が必要でした。 Rust は、より高い決定性を可能にすることで、そのデバッグの大部分を取り除きます。 この言語は、メモリ安全性の問題を解決すると同時に、並行性の問題を緩和します。

でも、これらは本当に自分のためのものなのか？

楽しめるなら、もちろんです！

システムプログラミングと低レベルセキュリティは気後れするようなトピックなので、特定の種類の人だけのものだと思うかもしれません。 従来は、実際そうでした。 現実的には、障壁はまだ存在します。

あなたの経歴や経験によっては、自分がシステムセキュリティの世界の一員である姿を思い描くのは難しいかもしれません。 しかし、あなたには確かにそれができます！ それは簡単ではないかもしれません——しかし、可能です。

1. Rust を学ぶ。The Rust Team（2021）。 ↩

2. The Rust Programming Language。Steve Klabnik、Carol Nichol（2022 年アクセス）。 ↩

3. プロセスとスレッド。OSDev Wiki（2021）。 ↩

4. 本番環境のユーザー。The Rust Team（2022 年アクセス）。 ↩

5. Ferrous Systems と AdaCore が Ferrocene で協力へ。Ferrous Systems（2022）。 ↩

6. AUTOSAR が Automotive Software の文脈におけるプログラミング言語 Rust の新しい Working Group を発表。AUTOSAR（2022）。 ↩

7. SAfEr Rust Task Force。SAE International（2022 年アクセス）。 ↩

8. Rust 検証ツール。Rust Formal Methods Interest Group（2021）。 ↩

9. ferrocene。Ferrous Systems（2023）。 ↩

10. 1978 年、米国国防総省（DoD）は、安全性が重要な組込みシステムに特化したプログラミング言語の要件リストを提示しました。その後、DoD は競技会（より現代的な DARPA の「Grand Challenges」とよく似たもの）を支援しました。赤、緑、青、黄の 4 つの言語設計チームが競い合いました。緑チームが勝利し、MIL-STD-1815-A 言語仕様を作成しました。彼らの言語は、先駆的なプログラマーである Ada Lovelace にちなんで「Ada」と名付けられました。1815 は Lovelace の生年でした。 ↩

11. Ada ランタイムライブラリおよびコンパイラの認証エビデンス。AdaCore（2022 年アクセス）。 ↩

12. SPARK について。AdaCore（2022 年アクセス）。 ↩

13. Ada と SPARK における安全な動的メモリ管理。Maroua Maalej、Tucker Taft、Yannick Moy（2021）。 ↩

14. dictobject.c。CPython Interpreter（2021）。 ↩

15. あまりにも多すぎるリンクリストで Rust を学ぶ。Aria Desires（2021）。 ↩

16. ムーアの法則。Wikipedia（2022 年アクセス）。 ↩

本書はどのように構成されているか？

結論から言うと、本書は大規模なプロジェクトを段階的な足場かけに沿って進めることで、専門性を身につける助けになります。 そのため、大半の読者にとっては、本書全体を順番に読むのが最善です。

しかし現実的には、誰もが教科書を最初から最後まで読む時間や気力を持っているわけではありません。 また、一部の読者はすでに特定のトピックに精通しています。 そこで、5種類の読者（いずれもすでに経験豊富なプログラマー）に対応するため、以下の内訳を用意しました。

推進モデル

本書では幅広い範囲を扱います。 そもそも「保証」とは何を意味するのかから、最先端技術の限界まで。 それらを貫く統一的な筋道は、段階的な集大成プロジェクト、つまり高度なライブラリを構築することです。

その筋道は、古典的な軸に巻きついています。それが、スキル習得のドレイファスモデル¹です。 この発達モデルは、正式な教育と実践的な練習がスキル開発においてどのように絡み合うかを説明します。 これはもともと、米空軍の研究イニシアチブの一環として資金提供を受け、1980年に UC Berkeley で開発され、現在でも妥当性を保っています。

ドレイファスの考えの核心は、複雑なタスクを意図的に上達させようとする人は誰でも、5つの明確な段階、すなわち Novice、Advanced Beginner、Competent、Proficient、Expert を通過できるというものです。

学習者の熟練度が高まるにつれて、抽象的な原則から得るものは少なくなり、具体的な経験から得るものが多くなります。 その結果、認知的注意（例: 負荷の高い集中）から自動処理（例: 「第二の天性」）へと移行します。

本書の内容は、5段階のうち最初の3段階を反映するようにおおまかに構成されています。 更新された（2004年頃の）定義²を使用しています。 各段階を説明し、関連する章を概観しましょう。

ドレイファスモデルの段階別の章

段階1 - Novice: システムセキュリティ

Novice は、ルール、すなわち特定の状況にかかわらず適用される「全体像」の原則を学び、手順に従います。

Novice 段階の章では、中心となる概念、定義、言語構文に焦点を当てます。

• 第2章 - ソフトウェア保証: セキュアで堅牢なソフトウェアを開発するためのツールとプロセスの全体像を理解します。最初の Rust プログラムを書きます！

• 第3章 - Rust ゼロ速習コース: Rust の機能と構文を巡り、借用チェッカーと調和して生き、コードを整理します。セキュリティと信頼性に関する業界のベストプラクティスガイドラインの文脈で扱います。さらに、プロフェッショナルなソフトウェアプロジェクトを維持するためのツール群のサンプルも示します。

• 第4章 - メモリを理解する: プログラムを「制御」するため、メモリ安全でないプログラムを悪用するため、そして Rust のメモリ安全性保証を機械的なレベルで本当に理解するために、メモリについて知っておくべきことを扱います。

段階2 - Advanced Beginner: コアプロジェクト

Novice とは異なり、Advanced Beginner は繰り返し現れるパターンを認識し始めます。 彼らは「格率」（緩やかで状況依存のルール）を見つけ、経験を積むことで自分独自の創造的な戦略を適用します。

Advanced Beginner 段階の章では、ライブラリのコア実装を開始します。 焦点は、これまで学んだ保証の概念を、自明でないコードに対応づけることです。

• 第5章 - 二分探索木（BST）の基礎: 基本的な探索アルゴリズムとソートアルゴリズム、木データ構造がその両方をどのように可能にするか、そしてこれらのアルゴリズムを Rust に移植する際の課題を扱います。

• 第6章 - アリーナアロケーターの構築: メモリ管理を制御することで、一般的なアルゴリズムを慣用的で安全な Rust コードに変換します。

• 第7章 - 自己平衡 BST: メモリ効率の高い自己平衡二分探索木を構築するため、高度なアルゴリズムを実装します。

• 第8章 - デジタルツインテスト: システム全体のエミュレーションと組み込みセミホスティングの入門です。リモートコマンドを受け取る小さな仮想マイクロコントローラー上で、私たちのライブラリを実行します！

• 第9章 - マップとセットの構築: 素朴な木を、Rust 標準ライブラリのコレクションに対する、おおむね API 互換の差し替え可能な代替に変換します。

• 第10章 - イテレーターの実装: Rust の中核的な抽象化の1つである安全なイテレーターをサポートすることで、ライブラリの有用性を大幅に高めます。

段階3 - Competent: 検証とデプロイ

Competent な学習者は、自分が何を知らないのかを認識できるほどニュアンスのある理解を発達させます。 それに対処するため、Competent な学習者は自己専門化を始めます。 彼らは、スキル領域のどの要素が自分の長期的なニーズにより役立つのか、そしてどの要素を優先度を下げるか、あるいは無視できるのかを判断します。

Competent 段階の章では、蓄積した教訓を実世界のプロジェクトに適用する準備をします。 セキュリティテストと機能検証のために高度なツールを使用する方法を学びます。 また、別の言語で書かれたより大きなソフトウェアプロジェクトの中に Rust コードを統合する方法も学びます。

• 第11章 - 静的検証: 演繹的検証（コンパイル時に定理証明器によって証明される仕様注釈）を使用して、コアコードが機能的に正しいことを示します。また、網羅性のために、unsafe コードのモデル検査も扱います。

• 第12章 - 動的テスト: 本番レベルおよび実験的なツールの両方を使用して、ライブラリとそのすべての依存関係にストレステストを実施します。ベンチマークと最適化も扱います。

• 第13章 - 運用デプロイ: ライブラリに CFFI バインディングを追加することで、現実世界の多言語プロジェクトにおける Rust の利点を引き出します。unsafe の徹底的な探究も行います（私たちのライブラリでは使用していませんが、多くのプロジェクトでは使用されています）。

• 第14章 - 保証の最大化: 一歩引いて Rust をより広い文脈で評価し、制限、ベストプラクティス、最先端の研究を見ていきます。

ステージ4と5（熟達者とエキスパート）はどうでしょうか？

熟達者のステージでは、学習者は概念、規則、スキルから目標へと移行します。 経験を身につけた彼らは、新しい状況において適切な目標を判断できます。たとえそれを達成する能力を常に持っているとは限らなくてもです。

エキスパートは、目標を判断し、それを効率的な手段で達成できます。 彼らは最先端をさらに進め、次世代の初心者のための新しい規則を作り出すことさえあります。

1冊の本を読むだけで、あなたがエキスパートになるわけではありません。 それは、キャリアを通じて現実世界の戦場で苦労して勝ち取る称号です。

とはいえ、最後の章はあなたへの餞別です。

• 第15章 - レビュー: 本書全体を密度の高いノート群へと凝縮したものです。理解を定着させるためにも、将来のクイックリファレンスとしても使えます。

熟達を経てエキスパートの地位へ向かう道は、舗装されていません。 進路を描くのはあなた次第です。 この本がその始まりとなることを願っています。

1. 指示されたスキル習得に関与する精神活動の5段階モデル。Stuart E.Dreyfus, Hubert L. Dreyfus (1980)。 ↩

2. 成人のスキル習得の5段階モデル。Stuart E.Dreyfus (2004)。元の論文とこの改訂版の両方について、提案された分類を正当化するために経験的・実験的データを用いていないとの批判があることに注意してください。 ↩

ハンズオン学習

ソフトウェア開発者もセキュリティエンジニアも、何よりまず実務家であり、理論家であるのはその次です。 基礎概念や状況に応じた文脈を理解することは、確かに重要です。 しかし結局のところ、あなたはコードを書き、実行します。 そして、そのコードが実行されている間に、他の誰かがそれを悪用しようとするかもしれません。

前述の Dreyfus Model は、正式な指導とハンズオンでの実践の両方を包含しています¹。 陳腐な表現かもしれませんが、習うより慣れろです。 あるいは、慣れることでエキスパートになる、と言うべきでしょう。 概念を理解するために本をざっと読むだけで学べることには限界があります。

Dreyfus の各段階を進んでいくには、コードを書き、実行し、デバッグする必要があります。 これは、各章で提示される例に沿って進めること、そしてより重要なのは、この本を出発点として、自分で選んだ現実世界のプロジェクトに取り組むことを意味します。

ここでの私たちの目標は、概念と転用可能なスキルを教え、現実世界での経験が現実的な可能性となるレベルまで到達してもらうことです。 言語学習の側面では、それは次のことに自信を持って取り組めるようになる時点です。

• Rust で書かれた既存のオープンソースプロジェクトにコントリビュートする。
• 自分で設計した Rust ライブラリを公開する。
• 職場の新しい取り組みに Rust を取り入れる。
• など。

章末チャレンジ

各章の最後には、任意のチャレンジがあります。 これらのチャレンジは、中程度から高い複雑さの機能を設計し、実際にコードとして実装することの両方を必要とする、自由度の高い問題です。

この本以外のリソースを見つけ、新しい文脈でその章の概念を適用し、自分なりの戦略を立てながら、解決策の空間を独力で探求する必要があります。

チャレンジの解答は提供されません。提案された問題に取り組むかどうかは、あなた次第です！ あるいは、あなたの意欲を高める個人的なバリエーションに取り組んでもかまいません。

1. 成人の技能習得の五段階モデル. Stuart E.Dreyfus (2004). ↩

チームについて

コアチーム

Tiemoko Ballo、著者 (tiemoko.com)

Tiemoko はシニアサイバーセキュリティ研究者です。 彼の経験は、米国国防総省の研究所における高度なツール開発、査読付き学術会議での発表、Fortune 100 企業でのインシデント対応に及びます。 カーネギーメロン大学で情報セキュリティの修士号を取得しています。

Moumine Ballo、技術編集者 (LinkedIn)

Moumine はシニアスタッフソフトウェアエンジニアです。 最先端のモバイル GPU に携わり、リソースに制約のあるコンソール向け AAA ゲームと自律走行車シミュレーションの両方でグラフィックスエンジンを作成してきました。 ワルシャワ工科大学でコンピューターサイエンスの博士号を取得しています。

Alex James、技術編集者 (buildbreak.net)

Alex はセキュリティソフトウェアエンジニアです。 Web スケールのセキュアアーキテクチャとクラウドインフラストラクチャに携わり、1日あたり 3 億人を超えるアクティブユーザーにサービスを提供する分散セキュリティシステムを設計・実装しています。 カーネギーメロン大学で情報セキュリティの修士号を取得しています。

コミュニティ貢献者

この本をより良くしてくれているすべての人に心から感謝します¹！ アルファベット順で掲載しています。

• aelnona
• asher-gh
• drlef
• Druthyn
• duzumaki
• humb1t
• jam1garner
• jamesreprise
• jkoeppeler
• KateMorley
• kaylynn234
• LoganDark
• Michcioperz
• pixelshot91
• qrilka
• rrevi
• samestep
• shak360
• SilvanCodes
• sshine
• tshepang
• U007D
• Vishal Lama

1. 貢献は歓迎され、感謝されます。詳しくは CONTRIBUTING.md を参照してください。 ↩

ウォームアップ: 環境セットアップ

警告: 本書のコンテナは現在機能していません。後日修正し、CI に追加する予定です。ローカルインストールなど、別の方法でツールチェーンをセットアップしてください。

通常の章末チャレンジの代わりに、ウォームアップを行いましょう: Rust ツールチェーンのセットアップです。 Rust プログラムを書き、コンパイルするために必要なものです。 これをあなたのブートストラップシーケンスだと考えてください！

本書は Linux ホスト上で開発されています。 各章を通じて、再入力（またはコピー/ペースト、右側のボタンに注目してください）して実行できるコマンドが登場します。 次のようなコードブロックリスティング形式です:

whoami

これらのコマンドは、一般的な Linux ディストリビューションを使用していることを前提としています。 一緒に進めるには、2 つの選択肢があります:

1. Linux ネイティブ: ホスト上に、紹介される各ツールを現在の公式ドキュメント（ここではすべてのインストール手順を重複して説明することはしません）またはディストリビューションのパッケージマネージャーを使用してインストールします。ほとんどのツールはセットアップが簡単で、多くの場合 1 つか 2 つのコマンドで済みます。

2. Docker コンテナ: Linux 以外のプラットフォームを使用している場合は、Docker¹（広く使われているコンテナ化ツール）をインストールし、本書で提供されている Dockerfile² を使って自己完結型の開発環境を構築します。

注: コンテナの現在の状態

本書のコンテナサポートは現在作業中です。 将来的には、コンテナは自動的にテストされ、その利用方法に関する詳細な手順が付録に追加される予定です。

現在は、本書のリポジトリ内にシンプルな Dockerfile を提供しています²。

どちらの方法を選ぶにしても、ツールチェーンが動作していることを確認する必要があります。

ツールチェーンを試す

rustup は Rust ツールチェーンの公式インストーラー兼アップデートマネージャーです。 ほかにも、Rust の以下をまとめて提供します:

• コンパイラ (rustc)
• パッケージマネージャー (cargo)
• 標準ライブラリ (std)

rustup は、stable、beta、nightly という 3 つの「チャネル」からツールチェーンコンポーネントを選択できます。 違いについては第 3 章で扱います。 また、他のプラットフォーム向けにクロスコンパイルするためのコンポーネントを追加することもできます。 第 8 章では、エミュレートされた ARM Cortex-M マイクロコントローラー向けにコンパイルします。

コンテナを使用しない場合は、こちらの手順に従って rustup をインストールできます:

• https://www.rust-lang.org/tools/install

インストールを確認するには、次のコマンドを実行します:

rustup --version

Rust プログラムをコンパイルして実行できることを確認しましょう。 hello_world という名前の新しいプロジェクトを作成するには:

cargo new --bin hello_world

tree hello_world を実行すると、次のディレクトリレイアウトが表示されるはずです:

hello_world/
├── Cargo.toml
└── src
    └── main.rs

1 directory, 2 files

Cargo.toml はビルド設定ファイルです。 このプログラムをコンパイルするために編集する必要はありません。 唯一のソースファイルである main.rs の内容を見てみましょう:

cd hello_world
cat src/main.rs

従来の “Hello, world!” プログラムがあらかじめ用意されています:

fn main() {
    println!("Hello, world!");
}

コンパイルして実行するには、hello_world ディレクトリ内から次を使用します:

cargo run

コンソールに挨拶が表示されれば、動作するツールチェーンを入手できています！

好みの IDE に rust-analyzer を追加する

rust-analyzer³ は、Rust 向けの Language Server Protocol⁴ の実装です。 複数のエディタや統合開発環境（IDE）と統合され、次のような便利な機能をサポートします:

• 構文/警告/エラーのハイライト
• コード補完
• 定義への “Goto” 機能
• シンボル名の変更

このようなワークフロー支援機能は、生産性を高めることができます。 言語の初心者にとっても、大規模なコードベースで作業するプロフェッショナルにとっても有用です。 必須ではありませんが、rust-analyzer または同等のもの（いくつかの商用 IDE は同様の Rust サポートを提供しています）をインストールすることを強く推奨します。

rust-analyzer を始めるには、そのマニュアルを参照してください:

• https://rust-analyzer.github.io/manual.html

任意の Docker ルート

Docker¹ は広く使われているコンテナ化ツールです。 コンテナを使うと、環境全体を再現可能かつ信頼性の高い方法で構築・設定できます:

• 産業界では、コンテナはネットワーク接続されたアプリケーションとその依存関係をまとめてパッケージ化し、クラウドインフラストラクチャへデプロイできる状態にします。

• 学術界では、コンテナはプロトタイプや解析をまとめ、研究結果を独立して再現できるようにします。

• オープンソースソフトウェアでは、コンテナはプロジェクトのビルドを自動化し、現在および将来のコントリビューターにとって参加の障壁を下げます。

私たちの動機は、オープンソースのユースケースに最も近いものです。 特定のプロジェクトをビルドするためのコンテナをセットアップするのではなく、Rust プロジェクトの開発向けに事前セットアップされたコンテナを使用します。

でも、学びたいのは Rust であって Docker ではありません！

現代のソフトウェア開発には、複数のツールやプロセスが関わります。 Docker は、特定のプログラミング言語が解決する問題とは直交する問題を解決します。

本書の文脈では、サンプルを実行し、ハンズオンチャレンジを完了するための、信頼できるサポートされた環境を提供してくれます。 「自分のマシンでは動いた」問題はありません。Windows、Linux、MacOS のいずれを実行していても、同じ手間のかからない体験が得られます。

少なくとも、既存の Docker コンテナをビルドして実行する方法を知っておく価値はあります。 それが本書で扱う Docker の範囲です。 高度な docker の使い方や Dockerfiles の書き方は扱いません。 また、以下の短い説明を除き、Docker の内部についても扱いません。

Docker は実際にはどのように動作するのでしょうか、一言で言うと？

従来の仮想マシン（VM）は、複製によって分離を提供します。つまり、システムのカーネルの上で、[Type 2⁵] ハイパーバイザーの上で、OS カーネル全体を実行します。 これはかなり遅くなります。ホストとゲストという 2 つの OS カーネルに加え、接着剤となるソフトウェアを実行することになるためです。

対照的に、Linux ホスト上の Linux Docker コンテナは、ホストカーネルの特別な機能（“control groups”⁶ と “namespaces”⁷）を活用して、あたかも別のファイルシステム上に存在するかのようにコンテナを分離します。 カーネルの複製はありません。

VM と比較すると、分離されたアプリケーションをより高速に実行でき（スループット）、かつ/または単一の物理マシン上により多く収めることができます（密度）。

本書の Docker コンテナを始める

Docker のプラットフォーム固有のインストール手順はこちらにあります:

• https://docs.docker.com/get-docker/

本書の Dockerfile はこちらにあります:

• https://github.com/tnballo/high-assurance-rust/blob/main/Dockerfile

お好みの IDE には、コンテナーへの接続や管理を行うためのプラグインが用意されている場合があります。 たとえば、VSCode には公式の拡張機能があります:

• https://code.visualstudio.com/docs/remote/containers

チェックポイント

先に進む前に、上記の “Hello, world!” プログラムのコンパイルと実行に成功していることを確認してください。 ネイティブ環境でもコンテナー内でも構いません。

次の章では、より興味深いプログラムを書いていきます。読み進めながら作業するには、動作するツールチェーンが必要になります。

1. Docker の概要 Docker (2022年閲覧)。 ↩ ↩2

2. https://github.com/tnballo/high-assurance-rust/blob/main/Dockerfile ↩ ↩2

3. rust-analyzer. rust-analyzer (2022年閲覧)。 ↩

4. Language Server Protocol. Microsoft (2022年閲覧)。 ↩

5. ハイパーバイザー: 分類。Wikipedia (2022年閲覧)。 ↩

6. Linux コンテナーについて知っておくべきすべてのこと、パート I: Linux Control Groups とプロセス分離。Petros Koutoupis (2018)。 ↩

7. Linux コンテナーについて知っておくべきすべてのこと、パート II: Linux Containers (LXC) を扱う。Petros Koutoupis (2018)。 ↩

ソフトウェア保証

米国国防総省（DoD）は、ソフトウェア保証を次のように定義しています¹。

… ソフトウェアが意図したとおりに機能し、ソフトウェアの一部として意図的または非意図的に設計または挿入された脆弱性が存在しないことに対する信頼の度合い。

これは簡潔な定義ですが、掘り下げるべき奥行きがあります。 政治的イデオロギーや国籍に関係なく、この定義は特定のシステムのセキュリティについて考えるための鋭いレンズです。

脆弱性：セキュリティ欠如の根本原因

これまでにプログラムを書いたことがある人なら、バグという考え方にはおそらく非常になじみがあるでしょう。これは、プログラムが誤動作する原因となる誤りです。 プログラムに存在するバグの一部は脆弱性である場合があります。つまり、攻撃者に悪用される可能性があるということです。 違いを明確にするために、2つのシナリオを対比してみましょう。

1. 有効な認証情報でログインできない場合は？

   • 認証が壊れています。
   • 正規ユーザーを含め、誰もデータにアクセスできません。
   • それはバグであり、ソフトウェアが正しく動作していません。

2. 無効な認証情報でログインできる場合は？

   • 認証が壊れています。
   • 攻撃者を含め、誰でもデータにアクセスできます。
   • それは、機密データの閲覧や変更に悪用される可能性のある脆弱性です。

DoDの定義は、バグがないことを「ソフトウェアが意図したとおりに機能する」という表現に包含していますが、セキュリティに関連する目標は、「脆弱性が存在しない」ソフトウェアへ近づくことです。 本書はその両方を扱います。 私たちは、堅牢でセキュアなシステムを構築したいのです。

率直に言えば、脆弱性が完全に存在しないソフトウェアや、絶対的にセキュアなソフトウェアはありません。 口語的に言えば、セキュアなシステムとは、攻撃のコストがあらゆる資産の価値を大きく上回るシステムです。 資産とは、ハードウェア、ソフトウェア、機密情報など、保護すべきシステムのあらゆる部分を指します。 攻撃を不可能にすることはできません。ただ、非現実的にすることはできます。

セキュリティ実務者として、私たちはソフトウェアエンジニアがバグを最小化しようと努めるのと同じように、脆弱性を兵器化最小化しようと努めます。 脆弱性が少なければ、現実的な攻撃も少なくなります。 しかし、後の章で取り上げる形式検証でさえ限界があります。 ハードウェアとの相互作用やソフトウェアコンポーネント間の相互作用はあまりにも複雑であり、任意のシステムが考え得るすべての脅威モデルに耐えられると誰かが完全に確信することはできません。

だからこそ保証

ここで「信頼の度合い」が重要になります。 一連のツールとプロセスを適用することで、その一部は本章で試しますが、ソフトウェアのセキュリティに対する信頼を築くことができます。 大まかに言えば、これらは次の3つのカテゴリのいずれかに分類されます。

• 静的保証 - 開発中および/またはテスト中に、コードを実行せずに行うチェック。

• 動的保証 - テスト中に、プログラムを実行して行うチェック。

• 運用保証 - ソフトウェアが本番環境で実行されているときに取られる対策。

この文脈で「本番環境」とは何を意味するのでしょうか？

情報システムが顧客にサービスを提供する環境です。 あなたが行うすべてのセキュリティ上の判断は、この環境の現実に基づいているべきです。

Webアプリケーションの場合、バックエンドコンポーネントについては「クラウド」（さまざまな地理的場所にプロビジョニングされた仮想マシン）を意味するかもしれません。そしてフロントエンドコンポーネントについては「クライアント」（アプリやブラウザを実行するスマートフォンのような、エンドユーザーが所有するハードウェア）を意味するかもしれません。

組み込みシステムの場合、本番環境は多種多様な冒険的な場所になり得ます。 自動車のケースでは、センサーとステアリングの両方に接続された、車のダッシュボード内の小さなコンピューター上です。

各カテゴリの理由と方法を理解するための概念的基盤を構築し、本書の大部分をその知識を実践的に適用することに費やします。 私たちはコードを書き、ツールを使うことに焦点を当てているため、高レベルのソフトウェアエンジニアリング²方法論は扱いません。 これには次のものが含まれます。

• システム開発ライフサイクル（SDLC³）： 任意の情報システムを計画、作成、テスト、デプロイするための一般的なプロセス。

• Microsoft Security Development Lifecycle（SDL⁴）： ソフトウェアセキュリティ脆弱性の発生可能性と保守コストを低減するためのフレームワーク。

このような方法論は価値のある設計図であり、本章の概念をそれらに対応付けることもできますが、ここでは議論しません。プロジェクトレベルのベストプラクティスが存在し、組織のリーダーシップとコミュニケーションするための共通言語を提供できることだけ知っておいてください。

DoDの定義では、一般にバックドアと呼ばれる、「意図的に…設計または挿入された」脆弱性という考え方にも言及しています。 私たちが書くコードは、Rustの標準ライブラリ⁵以外には、ごく少数の十分に信頼された依存関係しか持たないため、バックドアの検出については気にしません。 ただし、本章ではこのトピックをより直感的に感じられるように、単純なバックドアを目にすることになります。

Rustは、システムプログラミングの制約下で前例のないレベルの保証を提供するため、有望なセキュリティ技術です。 Rustコンパイラは、俗に「メモリ破壊バグ」と呼ばれる悪質な種類の脆弱性が存在しないことを証明できると同時に、同じ保証を提供できない言語のベアメタル性能に匹敵します。 次章ではメモリの仕組みと安全性を深掘りしますが、本章に入るにあたり、改めて強調しておく価値があります。

初めての高保証Rustプログラム

理論は基盤ですが、成長には実践的な経験が必要です。 さっそく始めましょう。 本章の後半では、Rustによる高保証システムプログラミングを初めて体験します。 200行未満のコード（テストを含む）で、次のことを行います。

• ほぼあらゆる組み込み環境で実行可能な小さな暗号ライブラリを実装する。

• 公式にリリースされたテストベクターを使用して実装を検証する。

• 動的テストが失敗する箇所を理解するために、素朴なバックドアを挿入する。

• コマンドラインフロントエンドを追加し、ライブラリを使ってローカルファイルを暗号化できるようにする。

行数はごくわずかですが、私たちのツールはモジュール化されたシステムになります。 信頼できるコンポーネントで構成されます。

サードパーティライブラリのメモリ安全性検証

Rustプロジェクトでは、オプション属性 #![forbid(unsafe_code)] を有効にできます。 これにより、単一のバイナリまたはライブラリの境界内で、unsafe の使用がコンパイル時エラーになります。

サードパーティの #![forbid(unsafe_code)] 依存関係をソースからビルドすると、外部エンティティから調達したコードがメモリ安全であることを、コンパイラが自動的に検証できます。 コンパイラ自体にバグがない限り。

しかし現実世界のチームは、自明でないシステム内の実行可能コードの1バイト単位すべてを検証できると期待することはできません。 その検証がメモリ安全性のためであれ、何らかの別の性質のためであれ同じです。 素早く出荷するために、私たちは次のようにします。

• フロントエンドを構築するために、Rustの標準ライブラリと広く使われているサードパーティライブラリに依存します。

• フロントエンドを構築するために、libc、つまりC標準ライブラリ（動的メモリアロケータ、POSIX APIなど）に推移的に依存します。

• エンドユーザーにインタラクティブな機能を提供するために、成熟したオペレーティングシステムに推移的に依存します。

私たちの目標は、自分たちが書くコードから高水準の設計上の欠陥、ロジックバグ、メモリエラーを排除することです。 攻撃者にとって唯一の現実的な選択肢が、標準ライブラリ、有名なサードパーティ依存関係の最新版、あるいはOS自体の脆弱性を見つけることだけであるなら、私たちのシステムを侵害するためのコストはおそらく高いでしょう。

しかし、それは本当に高保証なのか？

いいえ、私たちは意図的に譲歩しています。破られている暗号化アルゴリズムであるRC4を使うことです。 理由は2つあります。

• ソース行数を少なく保つため。RC4は単純なので、例として機能します。

• この章のチャレンジに取り組む動機を与えるため。このチャレンジでは、モジュール式CLIツールを最新の暗号化バックエンドに切り替えることを求めます。

RC4はかつて、SSL/TLSやWEPのように、私たちの社会が依存するプロトコルの一部でした。 しかし1987年の登場以来⁶、複数の弱点が発見され、いくつかの実用的な攻撃が実証されています。

これは重要な公理の縮図です。保証は動く標的です。 セキュリティ環境が変化するにつれて、要件や講じる対策も変わらなければなりません。

動機

先に進む前に、少し立ち止まりましょう。そもそも、なぜソフトウェア保証を優先するのでしょうか？

別のDoDの声明がそれをうまく要約していると言えるでしょう。 安全でないソフトウェアの代償に関する以下の説明では、“mission critical” を「ビジネスクリティカル」に置き換えて読んでも構いません¹。

結果: 敵はミッションクリティカルなデータを盗んだり改ざんしたりする可能性があり、ミッションクリティカルなプラットフォームの機能を破損させたり拒否したりする可能性がある

サイバースペースへようこそ。 このフロンティアを安全にしましょう！

学習成果

• 静的解析と動的解析のトレードオフを理解する
• 運用上のデプロイ対策の役割を理解する
• 最初の興味深いRustプログラムを書く: 小さな暗号化ツール
• 静的リンクされた実行可能ファイルのビルド方法を学ぶ（ほぼすべてのLinuxクライアントで動作）

1. DoDソフトウェア保証イニシアチブ. Mitchell Komaroff, Kristin Baldwin（2005年、パブリックドメイン） ↩ ↩2

2. ソフトウェアエンジニアリング知識体系ガイド. Pierre Bourque, Richard E. Fairley（2014年） ↩

3. システム開発ライフサイクル. Wikipedia（2022年アクセス）。 ↩

4. Microsoftセキュリティ開発ライフサイクル (SDL). Microsoft（2021年） ↩

5. Rustの標準ライブラリは、どんな大規模なソフトウェアと同様に、脆弱性がないことが保証されているわけではありません。以前に発見された2つの脆弱性には、unsafe コードにおけるメモリ安全性エラー⁷と、Time-of-check-to-time-of-use（TOCTTOU）競合状態⁸があります。しかし std は公式のRustチームによって保守されている広く使われているコンポーネントなので、一般的にはサードパーティパッケージよりも信頼できます。特にバックドアに関してはそうです。 ↩

6. 偶然にも、RC4の発明者であるRon Rivestは、第7章で実装するデータ構造であるスケープゴート木の共同発明者でもあります。スケープゴート木はRC4ほどの人気を得ることはありませんでしたが、確かに時の試練に耐えてきました。 ↩

7. CVE-2018-1000657の分析: RustのVecDeque::reserve()におけるOOB書き込み. GeorgiaTech SSLab（2022年アクセス）。 ↩

8. 標準ライブラリのセキュリティアドバイザリ (CVE-2022-21658). The Rust Team（2022年アクセス）。 ↩

静的ツールと動的ツール

ミッションクリティカルなアプリケーションの作者として、私たちは自分たちのコードにバグが少なく、脆弱性はたとえ存在するとしてもさらに少ない、と確信できなければなりません。 信頼性にとってセキュリティは必要ですが、それ自体だけでは十分ではありません。 私たちにはその両方が必要です。 しかし私たちは、不完全な要件群を相手に、時間やリソースの制約下でソフトウェアを書いています。 自尊心はさておき、私たちは自分たちの確信をどのように正当化できるのでしょうか。

その答えは、定量的に、です。 プロセスとツールを通じて、客観的な証拠の断片を十分に蓄積することによってです。 学術界では、これを検証と呼びます。 しかし、研究カンファレンスで称賛されるプロトタイプが、現実世界で大規模に利用できるほど成熟していることはめったにありません。 そのため産業界では、検証技術の実用的なサブセットを採用し、それをテストというラベルの下に置いています。

テストの目標は、ソフトウェアというコインの両面の一貫性を検証することです。

• 仕様: ソフトウェア製品に対するビジネス上重要な要件。通常は平易な英語で表現されますが、「ビジネスロジック」はツール固有の形式（アサーション、事前/事後条件、型状態など）でエンコードできます。

  • 平易な英語の例: 当社の Web アプリケーションは、ネットワークベースの攻撃者からユーザーのデータを保護しなければならない。

• 実装: ソフトウェア製品の設計と動作を、実際のコードとして表現したもの。

  • 例: その Web アプリケーションは、業界標準の Transport Layer Security (TLS) ライブラリである OpenSSL¹ を使用して、ネットワーク経由で送信されるデータを暗号化し（機密性）、転送中にデータが破損していないことを検証し（完全性）、データの送信者/受信者の身元を検証します（認証）。

仕様と実装が整合していることを示せるなら、私たちは確信を得られます。 ここで、私たちのプログラムを解析するツールが登場します。 すべての解析ツールは、小さな証拠の断片、つまり仕様と実装のごく小さな一致を出力します。 それらは、コードレビューやセキュリティ評価のような手作業のプロセスの代替ではありません。熟練した人間の「頭脳」には及ばないからです。 ツールはむしろ補助であり、コストを削減し、スケールを容易にします。

人間と違って、ツールは容赦なく勤勉です。疲れたり、気が散ったりすることがありません。 また、たとえ偽陽性の場合（存在しないバグを報告する場合）であっても、完全に一貫しています。 メモリ安全性違反のような特定のセキュリティ問題を検出するうえで、一貫したツールは保証を達成する最善の方法です。

Rust は完璧には程遠いものです。 しかし、信じられないほど現代的なコンパイラを備えているため、商業的に実用可能なプログラミング言語と、特定のランタイム信頼性プロパティを検証する洗練されたツールとの境界を曖昧にしています。 型システムがその二つを橋渡しし、ツールチェーンがその恩恵を民主化します。 私たちは、確信を抱かせる次のような問いに、実証可能な形で答えることができます。

• 私のプログラムは実行時にメモリエラーに遭遇することがあり得るのか。

  • Rust のコンパイラは、私たちのコードを初めてビルドするときにその答えを提供します。
  • これは静的解析です。プログラムは一度も実行されていません。
  • その答えは、プログラムが到達し得る現実的な状態の大半²に適用されます。
  • これは*安全性プロパティ³*です。プログラムが悪い状態に到達し得ないことをチェックします。

• この特定の入力が与えられた場合、私のプログラムは正しい結果を生成するのか。

  • Rust の公式パッケージマネージャーである cargo は、ユニットテストの実行時に答えます。
  • これは動的解析です。プログラムの一部が具体的な入力で実行されました。
  • その答えは、あなたがテストした状態と、それらに意味的に近い状態にのみ適用されます。
  • これはライブネスプロパティです。プログラムが良い状態に到達することをチェックします。

メモリ安全性に関する問いはコンパイル時に静的に答えられ、入出力の正しさに関する問いは実行時に動的に答えられることに注目してください。 静的/動的という二分法は、解析ツール設計の核心にあります。

静的解析と動的解析は、対立しながらも補完し合う力という点で、一種の「陰と陽」⁴です。 その二元論的な性質にふさわしく、それらは異なるアルゴリズムと技術に支えられた、対照的な長所と短所の集合を提供します。

ユニットテストとは何か。

プログラムのサブセットに対する、手書きだが自動実行可能なチェックです。 通常は個々の関数を呼び出し、戻り値または副作用を検証することで実装されます。

ユニットテストは誤り得るものであり、多くの場合不完全ですが、より高い意味的洞察があるため、自動化アプローチの大多数よりも優れています。 動的解析に入るときに、ユニットテストを一通り見ていきます。

実務エンジニアのための全体像

コンピューターサイエンスの領域に入り込みすぎる前に、実務エンジニアの視点から解決空間を分解してみましょう。 私たちは、テストプロセスを迅速化するか、スケールさせる必要があるために、ツールに関心を持っていると仮定します。 大まかに言って、今日の静的ツールと動的ツールをどのように分類できるでしょうか。

一つのアプローチ⁵は、X 軸に静的 vs. 動的、Y 軸に既知のバグ vs. 未知のバグを置いた四象限です。

番号順に、左から右、上から下へと象限をたどっていきましょう。 地平線より上では、未知のバグを見つけられます。 これは、既存のデータを必要とせず、まったく新しいバグを発見することを意味します。

1. 静的、未知のバグ (S, U) - 既存のソースコードまたはビルド成果物を取り込み、解析を使ってバグを見つけたり、プロパティを証明したりします。プログラム自体は実行しません。

   • ツールの例: rustc（本書全体）。

2. 動的、未知のバグ (D, U) - 具体的なテストケースを生成し、これらの生成された入力でプログラムを実行します。実行時の振る舞いからフィードバックを収集する可能性もあります。

   • ツールの例: libFuzzer（第12章）。

地平線より下では、シグネチャデータがすでに利用可能な、事前に発見されたバグだけを検出できます。 つまり、既知のバグです。

3. 静的、既知のバグ (S, K) - ソフトウェアシステムの構成を解析し、依存関係に既知の脆弱なバージョンや既知のバグのある設定がないかをチェックします。

   • ツールの例: cargo-audit（第3章）。

4. 動的、既知のバグ (D, K) - 稼働中の資産またはサービスに問い合わせ、それらのバージョンや設定をフィンガープリントします。

   • ツールクラスの例: ネットワーク脆弱性スキャナー（本書では扱いません）。 どのアプローチであっても、報告されたバグの一部は、アプリケーションやサービスというより広い文脈において、悪用可能な脆弱性である可能性があります。 したがって、一般的なソフトウェアセキュリティのワークフローは次のようになります。

5. ツールから結果を収集する。

6. それらのレビューをトリアージする。

7. 優先度の高い脆弱性の修正を開発する。

8. パッチ適用済みの製品をテストする。

9. 修正を本番環境にデプロイする。

このサイクルをより速く進められるほど、より良くなります。 少なくとも、機能追加のペースに追随できる必要があります。 理想的には、セキュリティテストは新機能のロールアウトを支援し、既存の攻撃対象領域をプロアクティブに堅牢化できます。

では、未知のバグを見つけるツールがあるなら、既知のバグをチェックするツールはそもそもなぜ必要なのでしょうか？ 第1象限と第2象限のツールを使って、存在するすべてのバグを見つけるだけではだめなのでしょうか？

残念ながら、答えはノーです。 多くのバグクラスは、どのような種類のツールや分析を使っても自動的には検出できません。 その理由については、後のセクションで制限について説明するときに取り上げます。 ほとんどのバグは熟練した人間によって発見され、第3象限と第4象限のツールが検出できるシグネチャに変換される必要があります。 繰り返しますが、ツールはスケールのための補助であり、知性の代替ではありません。

まとめ

ソフトウェア保証には「信頼の水準」が伴います。 テストは、ビジネスに関連する仕様と、システムまたは製品の特定の実装が一致しているという信頼を強化します。

静的解析は、プログラムを実行せずにそのプログラムについて推論するもので、あるバグクラスが存在しないことを証明するのに適している傾向があります。 しかし、そのクラスは限られています。 多くの場合、偽陰性はありません（解析は何も見逃しません）。

動的解析は、プログラムを実行するもので、少なくとも1つのバグを見つけるのに適している傾向があります。 しかし、それはどのような種類のバグでもあり得ます。 多くの場合、偽陽性はありません（解析結果は真です）。

どちらのアプローチでも、既知のバグ（例: 既存のCVE）と未知のバグ（例: ゼロデイ）を見つけることができます。 頭が冴えているうちに、まず静的解析に取り組みましょう。 これは、この2つのうち理論的により複雑な方です。

1. OpenSSL。The OpenSSL Project（2021）。 ↩

2. 「ほとんど」は、その解析が推論できる範囲外のドメインを除外しています。これは、電力やタイミングに関するハードウェアサイドチャネル（ハードウェアと物理世界との相互作用に関する何かが脆弱性を生み出す場合）のようにモデル化が難しいためかもしれません。あるいは、解析を行うコード内のバグやその設計上の欠点によって、推論可能なドメインに制限が生じるためかもしれません。 完全に万全なものはありません。絶対的なセキュリティは存在しません。 ↩

3. ここでいう「安全性プロパティ」は、私たちの問いが対象としている仕様の種類を分類するために使用される一般的な用語です。メモリ安全性は、安全性プロパティの具体例の1つにすぎません。 ↩

4. 陰陽。Wikipedia（2022年アクセス）。 ↩

5. CSE545 Week 12: 6 Reasons to Love Fuzzing。David Brumley（2020）。 ↩

静的保証（1/2）

静的解析は混乱を招くことがあります。 あるプログラムをテストしたいとします。それを P と呼びましょう。 P を一度も実行しないなら、それが何をするのか、あるいは何をできるのかを、いったいどうやって知るのでしょうか？

静的解析ツールは、特定の問いに答えることを単純化する間接化の層を使うことがよくあります。 それらは P の構成要素を、解析固有の抽象ドメインに対応付けます¹。 この表現は、P の1つ以上の性質を反映するように設計されています。 それを解析することで、P について結論を導き出せます。

実行可能ファイルをビルドするためにコンパイラーを使ったことがある、あるいはスクリプトを実行する前にインタープリターに構文をチェックさせたことがあるなら、あなたは静的解析が実際に働いているところを目にしています。

解析それ自体がプログラム（あなたが選んだコンパイラーやインタープリターの内部にあるもの）であり、独自の特殊なアルゴリズムを実行します。それを「解析器」Q と呼びましょう。 私たちは Q を実行して結果を得るので、P（その結果が適用される対象）を実行する必要はありません。 これは静的解析を理解するための、[皮肉にも動的な] 1つの方法です。

具象 vs. 抽象:

動的解析がプログラムを実行することで一連の具象状態を観測するのに対し、静的解析は可能な抽象状態を要約します。 各抽象状態は、一連の具象状態を表します。

プレイヤーが1から10までの数（両端を含む）を選ぶ、単純な「数当てゲーム」プログラムを想像してください。 プレイヤーが 7 を入力すると、プログラムは you win! と出力します。 それ以外の場合は you lose と出力します。

プレイヤーが 3 を入力した実行に対する動的解析では、内部変数 x が 3 に設定され、分岐の片側が選ばれ、対応する you lose 出力が行われることを観測します。 これらはすべて具象イベントです。

ある種の静的解析²なら、このプログラムには2つの抽象状態があると結論づけるでしょう。すなわち、x == 7 の場合に you win! 出力へ至る状態と、x != 7 の場合に you lose へ至る状態です。

静的プログラム解析における課題

ここでは、未知のバグを見つけるための静的解析（前の図の左上の象限）について話していると仮定します。 このユースケースに適用すると、静的なアプローチにはトレードオフがあります。 一般的に言えば、次のとおりです。

• 長所: ドメインから導かれた結論は、プログラムのすべての可能な実行に適用できる場合があります。つまり、あらゆる可能な入力に対して成り立つ可能性があるということです！これは信頼度を最大化するのに役立ちます。

  • 静的解析は、最良の場合、特定のバグクラスが存在しないことを証明できます。

• 短所: 実物ではなく抽象表現を使っているため、静的解析の中には過大近似したり、さらに悪いことに停止しなかったりするものがあります^{3 4}。

  • 過大近似は偽陽性の結果を生みます。つまり、解析の限界により、見つかったバグの多くが本物のバグではないということです。誤った結果のバックログを抱えることは、忙しいエンジニアリングチームの足かせになります。

  • 停止しないことは、解析が決して結果を出力しないことを意味します。これは「状態爆発」、つまり解析が推論しようとしている問題の複雑さが組み合わせ的に増大することが原因で起こる場合があります。永遠に回り続けるのを避けるため、多くの商用ツールは近似によって複雑さを低減します。これもまた、偽陽性のリスクを伴います。

停止するほど実用的でありながら（状態爆発がなく）、偽陽性を一切生み出さないほど賢い（過大近似がない）静的解析アルゴリズムを設計することは、驚くほど多くの場合、不可能です。 「現在の知識と計算能力では不可能」という意味ではありません。 その問題が数学的に決定不能であるという意味で、証明可能に不可能なのです^{5 6}。

• 決定不能とは、任意のケースに対して正しい yes-or-no の判定を下せるアルゴリズムは、今後決して存在しないということです。

よい知らせがあります。アルゴリズム設計者は、賢明なトレードオフを選ぶことができます。 時には、許容できる程度の過大近似を受け入れることを意味します。 また別の時には、規則、制約、仮定、注釈を導入することを意味します。すべては、より精密な解析を実用的にするためです。

Rust も例外ではありません。 この言語はプログラマーに一定の制約を課します。 これらの制約は Rust の学習を難しくし、それによって可能になる解析はコンパイル時間の鈍化を引き起こすことがあります。 チームによっては、それらのトレードオフを受け入れられない場合があります。

すべての静的解析ツールにトレードオフが必要な理由について大まかな直感を身につけられれば、将来出会うどんな静的ツールや技術についても推論できるようになります。 高額なライセンス費用のかかるプロプライエタリな静的解析器も含めてです。 そこで、実践的な文脈で制限を探ってみましょう。ポインター解析です。

ケーススタディ: ポインター解析

ポインター解析（別名「points-to」解析または「may-alias」解析）について、非常に高いレベルで説明します。 そのため、big-step semantics⁷ を用いた Steensgaard のアルゴリズム⁸ の解説は行いません。 私たちの目的は、プログラミング言語（PL）形式論⁹ の「記号のスープ」に溺れることではなく、実践的な直感を築くことです。

なぜこの特定の種類の静的解析を見るのでしょうか？ ポインター解析は、実世界のメモリ安全でないシステムコードに対して性質を検証する際の課題を示す典型例です。 この議論は、Rust が静的に解決する深刻な問題を深く理解する助けになります。 また、この言語の厳格な規則の根拠を理解する助けにもなります。

ポインターとは何か？

C や C++ を書いたことがないなら、おそらく「生ポインター」の恐怖から守られてきたことでしょう。 しかし、Go や Java のような言語でさえ nil/NULL ポインターに対して例外を投げます（Rust はこの「10億ドルの過ち」¹⁰を修正します！）。C 系言語の場合を見てみましょう。

ポインターは、メモリ内の場所のアドレスです。 通常、ただし常にではありませんが、そのメモリは「仮想」です。つまり、マシン上の物理メモリ（CPU キャッシュ、RAM、HDD など）の上にある抽象化です。 機械的には、アドレスは符号なし整数として表現されます。

ポインターは一般に、データ（たとえば配列、構造体、オブジェクト）へ「参照によって」アクセスするために使われます。 これは、潜在的に大きなオブジェクトをコピーする必要がないことを意味します（別名「値渡し」）。 ポインターは従来のシステムプログラミングにとって重要な道具です。 メモリの効率的な利用を可能にします。

しかし、ポインターは諸刃の剣でもあります。 ポインターは、壊滅的な誤用が驚くほど簡単です。 ポインター演算における off-by-one エラーは、誤ったデータを読み取ってもそれに気づかないことを意味し得ます。無効なポインターにアクセスしようとすると、良くてもクラッシュです。攻撃者がポインターの値を設定できるなら、あなたのプログラムは悪用可能かもしれません。 「足を撃つ銃」だと考えてください。

ポインター解析には1つの目標があります:

• 各ポインターが実行時にどの変数やオブジェクトを指す可能性があるかを判定する。

その情報があれば、データがどこから読み取られる可能性があるか、どこに書き込まれる可能性があるかがわかります。 「可能性がある」とするのは、プログラムの実行ごとに異なる場合があるためです。 あらゆる潜在的な実行を代表する可能性の集合が必要です。 この情報により、プログラムについて強く、信頼感を与える主張を行えます。

すべてを欺く一行

その目標を念頭に置いて、次の1行のC関数を考えてみましょう¹¹:

void incr(int* a, int* b) {
    *a += *b;
}

この一見無害な小さな関数は、羊の皮をかぶった狼です。 この関数がより大きなプログラムの一部である場合、ポインター解析では a と b が同じ整数を指す（別名「エイリアス」）かどうかを判断できません。 解析結果は不確定になります。つまり、パラメーターは「エイリアスするかもしれないし、しないかもしれない」と結論づけます。 典型的な過大近似です。

Cを見るのはこれが初めてかもしれないので、ここで何が起きているのかを少し分解してみましょう。

• incr は関数名で、increment の略です。この関数は何かの値を増やすのだろうと推測できます。

• 関数パラメーターは括弧の中に現れます。この関数は a と b という2つの引数を取ります。どちらもメモリ内のどこかに格納された整数へのポインターです。

  • 関数シグネチャ内の * 演算子はポインターを表します。

  • したがって int* は「整数へのポインター」を意味します。

• 戻り値の型である void は、この関数が何も返さないことを示します。したがって、何らかの「副作用」（プログラム状態の更新）を持つのだろうと推測できます。

• 関数本体は、a と b が指す整数それぞれの現在値を（メモリから）読み取り、int b の値を int a に加算し（ポインター加算ではなく整数加算）、その合計で int a を更新します。

  • *a += *b; は *a = *a + *b; の省略形で、セミコロンで終わる文です。

  • ここでは、シグネチャ内とは異なり、* 演算子は「ポインターをデリファレンスする」、つまりその参照先の値を読み取ることを意味します。

  • * は + より優先順位が高く、読み取りが先に発生することを意味します。ポインター算術では優先順位の間違いが厄介になることがあります。

incr を呼び出す前に、int a の値が 40、int b の値が 2 だとします。 ポインター *a と *b は、それぞれメモリ内の対応する整数を次のように指します。

incr(a, b) を呼び出すと、int b が int a に加算されます。したがって呼び出し後は、次のようになります。

それは「慣用的な」Cコードですか？

いいえ。整数は通常、値渡しされます（整数へのポインターではなく、整数そのもの）。 整数はCPUのスクラッチ用メモリの小さな領域、つまり「レジスタ」にきれいに収まるため、そのほうが効率的です。 それでも、私たちの incr 関数は、参照されたデータを操作する日常的なCコードを代表しています。 これから導く結論は広く適用できます。

では何が問題なのでしょうか？

構文を理解してしまえば、incr 関数は非常に単純です。2つの数値を足し合わせるだけです。 なぜこれがポインター解析の実践にとってそれほど大きな課題なのでしょうか？

これらの「生の」（制約のない、という意味¹²）ポインターは、2つの自明でない複雑さをもたらします。

• 1. 決定不能なエイリアシング: 2つのポインターが同じメモリ位置を参照している（エイリアスしている）とします。その場合、a をインクリメントすると b もインクリメントされます。これはプログラマーが意図したことではない可能性が非常に高く、この関数が行うことを変えてしまうエッジケースです。しかし、これが起きないことを証明することはできません⁵。スケーラブルで正確なポインター解析は、依然として未解決の研究課題だからです。

  • 含意: 追加のコンテキスト（incr が呼び出されるすべての場所、別名「コールサイト」など）が与えられても、この関数が実行時に何をするかについて詳細な主張を行うことはできません。以下に示す望ましくないケースは、どのツールでも正確に検出できません。

  • 根本原因: 解析領域内での過大近似です。ポインター解析の設計者は、結果の精度について意識的なトレードオフ（「エイリアスするかもしれないし、しないかもしれない」という結論を許容するなど）を行う必要があります。

• 2. 複雑なメモリモデル: 生ポインターは無効なメモリ位置に設定される可能性があります。プログラマーがオフセットを計算するときにポインター算術のバグを混入させることもあります。あるいは単に、ポインターを「未初期化」のままにする（Cにおけるデフォルト状態）こともあります。

  • 含意: ポインターのデリファレンスはクラッシュにつながる可能性があります。あるいは任意のデータの読み取りや書き込みになる可能性もあります（クラッシュはしないが、プログラムの出力や挙動が不正になる）。

  • 根本原因: 解析領域外での過大近似です。これは抽象化境界の産物です。この場合は、ハードウェア/ソフトウェアインターフェイスにおけるセマンティクスの違いです。

まとめましょう。 エイリアスでしょうか？ プログラムが期待どおりに振る舞わないかもしれません。 私たちには判断できません。 無効なポインターでしょうか？ プログラムがクラッシュするかもしれませんし、別の値が上書きされて不正になるかもしれません。 やはり、これが起きないことを証明することはできません。

incr 関数は単純に見えますが、静的保証にとって克服できない課題を生み出します。 このプログラムが意図した加算を実行すると主張することはできません。 指し示せる証明がなければ、私たちの確信は低いままです。

現実世界におけるポインターエイリアシング問題

オープンソースのCコンパイラーである gcc は、効率的なコードを生成することを目指しています。 任意の2つのポインターがエイリアスするかどうかを確実に判断することは不可能なので⁵、gcc は少しずるをします。-O1 より大きい最適化レベルでは、2つのポインターが異なる型を指している場合、コンパイラーはそれらがエイリアスしないと仮定します。 この仮定により、影響の大きい特定の最適化が可能になります。

しかし実際には、Cプログラマーがこの仮定に違反することがあります（「型パンニング」と呼ばれるテクニックがあります）。 そのような場合、最適化によって厄介なバグや予期しない挙動が生じる可能性があります。 そのため、Linuxカーネルでは gcc フラグ -fno-strict-aliasing によって、この最適化が明示的に無効化されています^{13 14}。

ポインター問題のまとめ

静的解析には2つの失敗モード（相互排他的ではありません）のリスクがあります。過大近似、および/またはスケールしない/終了しないことです。 どちらも、静的解析ツールから引き出せる保証価値を制限します。 メモリ安全でない言語に対するポインター解析は、現実世界の問題を過大近似せざるを得ない古典的な例です。 ポインター（例: 自由に制御できるメモリアドレス）はシステムプログラミングにとって便利な抽象化ですが、実行時について自動的に推論する能力を著しく損ないます。 人間にとっても、それを正しく扱うのは困難です（ポインターは、C プログラムが「segmentation fault」¹⁵クラッシュで悪名高い理由の一部です）。

生ポインターは、既存の C/C++ コードからメモリ安全性の問題を排除することが現実的でない理由の 1 つにすぎません。 少なくとも、後方互換性を壊さずに行うことはできません。 覚えておいてください。メモリ安全性は、数十年にわたって困難であり続けている問題です。 多くの人が挑戦し、そのほとんどは失敗してきました。

Rust がポインターの問題をどのように扱うのか、少し見てみましょう。

不正確な解析でも有用であり得る！

ポインター解析には近い親戚があります。それが Value Set Analysis（VSA）です。 これはコンパイル済みバイナリに適用でき、ソースコードが利用できないユースケース（例: リバースエンジニアリング）を支援します。 ポインター解析とは異なり、VSA はポインター変数と整数変数を区別しません。 どちらの種類の数値変数についても、実行時に取り得る値の範囲を計算します。

上記の incr の例では、正しいプログラムに対する精密な VSA は、整数 a が [40, 42] という両端を含む値範囲を持つと判断するかもしれません。これはインクリメント前とインクリメント後の両方の値を捉えています。そしてポインター *a も同様に、有効なメモリアドレスの何らかの範囲内にあり、概念的には [0x7ffe455e5c40, 0x7ffe455e5bf0] のようなものになります。

ここが重要です。最近の査読付きヒューマンスタディ¹⁶では、不正確な（例: 過大近似の）VSA の結果であっても、プログラムが機密情報を出力するかどうか（例: 「情報漏えい」脆弱性を見つける）を判断するリバースエンジニアの能力を向上させることが示されました。 不正確な VSA の結果を利用することで、経験の浅いリバースエンジニアでも、特定の問題タイプについては、支援を受けない経験豊富なリバースエンジニアと同等の性能を発揮できました¹⁶。

近似的な静的解析は、多くの文脈において、実証的に有用であり得ます。

1. 抽象解釈: 不動点の構成または近似によるプログラムの静的解析のための統一束モデル. Patrick Cousot, Radhia Cousot (1977). ↩

2. プログラム変数に対する制約（x != 7 のようなもの）に従って結果を分解することは、「シンボリック実行」の特徴です。これは特に強力なプログラム解析です。理論上、シンボリック実行は純粋な静的解析です。しかし実際には、具体的な動的実行からのフィードバックを用いて実装されることが多くあります（別名「コンコリック実行」）。 ↩

3. 17-355/17-665/17-819 プログラム解析. Jonathan Aldrich et al, Carnegie Mellon University (2021). ↩

4. CIS 547 ソフトウェア解析. Mayur Naiak et al, University of Pennsylvania (2021). ↩

5. ポインターが引き起こすエイリアシング: 問題の分類. William Landi, Barbara Ryder (1990). ↩ ↩2 ↩3

6. 精密なフロー非依存 May-Alias 解析は NP 困難である. Susan Horowitz (1997). ↩

7. 講義 11: ポインター解析. Rohan Padhye, Jonathan Aldrich. Carnegie Mellon University (2021). ↩

8. ほぼ線形時間での Points-to 解析. Bjarne Steensgaard, Microsoft Research (1996). ↩

9. そうは言っても、形式的な記法には価値があります。それを学ぶことで、特定の問題についての考え方が変わることがありますし、少なくとも最先端の研究論文を読めるようになります。 ↩

10. Null References: 10 億ドルの過ち. Tony Hoare (2009). ↩

11. より安全な Rust: Creusot によるプログラム検証. Xavier Denis (2021). この講演から借用した関数は、Rust の型システムが検証をどのように支援するかを示すために使われました。次のセクションではこの考えを探りますが、異なる文脈で扱います。 ↩

12. ただし、ここでの「無制限」とは、現在の実行環境に対して相対的なものです。OS がプログラムに割り当てたプロセス空間のような「サンドボックス」（メモリセグメンテーションの強制）は存在します。このような制限により、あるプログラムのバグやエクスプロイトが他のプログラムや OS 自体に影響を及ぼす可能性が低減されます。 ↩

13. Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning. Linus Torvalds (2009). ↩

14. 未定義動作: 私のコードに何が起きたのか？. Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, M. Frans Kaashoek (2012). ↩

15. 「segmentation fault」、略して「segfault」は、プログラムが自分に属さない（割り当てられた「セグメント」の外側の）メモリ領域にアクセスしようとしたときに、オペレーティングシステムによって送出されるエラーです。デバッグは苛立たしいものになり得ますが、OS が止めてくれなかったらどれほど大変になるか想像してみてください！ ↩

16. 精密および不精密な Value-Set Analysis（VSA）情報が手動コード解析に与える影響. Laura Matzen, Michelle Leger, Geoffrey Reedy (2021). ↩ ↩2

静的保証（2/2）

これで、静的プログラム解析における課題について、非形式的な理解が得られました。 あるいは、ポインター解析がなぜ難しいのかについて、いくつか直感を得られただけかもしれません。 そして厄介なことに、ポインターは私たちのシステムプログラミングに欠かせない存在です。 高性能なソフトウェアを書くには、参照渡しのセマンティクスが必須です。

ここから Rust におけるトレードオフが始まります。 まず、生ポインターを捨て、代わりに参照に頼らなければなりません（これについては後述します）。 次に、参照を使うときには常に従わなければならないルールがあります。

しかし、本当に昔ながらのポインターが必要な場合はどうなるのでしょうか？

抽象化は、「その前提が、それが存在するコンテキストと一致している」場合に有用です¹。 ポインターは、メモリとの相互作用を容易にする抽象化です。

プログラムを安全な Rust の制約内で表現できない場合²でも、unsafe キーワードを使ってそのプログラムを書くことができます。 このキーワードが示すとおり、限定されたスコープについて、コンパイラによって強制される特定の安全性保証を放棄することになります。 unsafe ブロックの内部では、自らの責任で生ポインターを使用できます。 正しさの証明責任は、プログラマーであるあなたの肩に完全にかかっています。

そのような「オプトアウト」メカニズムがあることは、解析を完全に中止するよりも優れています。 実際、unsafe により、既存の C コードとのシームレスな統合が可能になります。 その相互運用性が、Rust の実世界での利用の多くを可能にしています。

unsafe は弱点ではないのでしょうか？保証をすべて失うのではないでしょうか？

正確にはそうではありません。 Rust の型システムの形式的検証に関する研究は、unsafe が存在していてもセキュリティ上の主張を維持できることを示しています³。

形式手法を使わなくても、安全な抽象化はunsafe な操作の上に構築できます⁴。 どのように呼び出されても安全性の不変条件を維持するインターフェイスを、注意深く設計できます。 内部で unsafe を使っているにもかかわらずです。 ただし、そのような設計の正しさをコンパイラが自動的に検証することはできません。 第13章では、unsafety と unsoundness の違いについて説明します。

しかし、もっと単純な見方を考えてみましょう。使用する unsafe が少なければ少ないほど、メモリ関連のバグについて監査しなければならないコード全体は少なくなります。

コードベースが safe と unsafe で 50/50 に分かれている場合でさえ、セキュリティレビュー、デバッグ時間、パッチのデプロイにかかるコストを大幅に節約できます。これは、後者の unsafe な半分が、安全な Rust と相互運用する C や C++ である場合でも当てはまります。

Rust の静的戦略

以下は、私たちのお気に入りの小さな厄介者である C の incr 関数を、Rust で書き直したものです。

fn incr(a: &mut isize, b: &isize) {
    *a += *b;
}

C 版を一つひとつ分解したので、この関数が何をするかはすでにご存じでしょう。 少し時間を取って、上のコードを確認してください。 構文について、いくつか推測できますか？

関数の本体はまったく同じです。 * は依然として逆参照演算子です。 += は同じ省略記法です。 isize は符号付き整数を表すキーワードで、C の int と同じようなものです。

しかし、Rust と C の incr 関数には 2 つの違いがあります。 1 つ目は細かな点です。戻り値の型がありません。 void が暗黙に指定されます。Rust では、関数が実際に値を返す場合にのみ、明示的な戻り値の型注釈が必要だからです。

2 つ目の違い、つまりポインターを使わなくなったという事実のほうが、はるかに重要です。 関数シグネチャを見ると、次のようになります。

• & は参照です。これはポインターに似ていますが、任意の値にはなれません。Rust は、それが初期化済み変数の有効なアドレスであることを保証します。

  • 前のセクションで述べたメモリモデルの問題を修正したことになります。逆参照演算子 * を使うとき、クラッシュしたり不正なデータを読み取ったりするリスクはありません。

• &mut は「可変参照」を意味します。この関数は、a が指す変数に書き込む能力を得ます。b についてはそうではありません。b は取るに足らない「不変参照」（単なる &）だからです。Rust は今や、任意のデータ片について、任意の時点で可変参照は 1 つだけ存在することを保証します。

  • 任意の時点で可変参照が 1 つしか存在できないなら、b が a と同じデータ片を参照することはできません。2 つのパラメーターは、決してエイリアスしないことが保証されています。

Rust について今述べたことの重大さを振り返る価値があります。 強力な静的保証の世界全体が開かれたのです。

前のセクションでは、incr 関数について議論しながら、判定不能なエイリアシングが過大近似を強いること、クラッシュの可能性、任意メモリの読み取りなど、悲哀に浸っていました。

その関数を Rust に移植すると、それをコンパイルする（実行可能プログラムを作成する）という行為だけで、このプログラムが期待どおりに 2 つの異なる整数を加算することを実際に証明します。つまり、計算機科学者たちは、Rust の型システム（それらの保証の源です^{5 6}）の形式的検証⁷について初期の研究を行っています。

Rust が適している場面で Rust を活用することで、高いレベルの保証を得られます。 少なくともメモリ安全性に関してはそうです。 それでも、incr のビジネスロジック（incr がインクリメントしている値の大局的な意味や、それらをインクリメントすることに意味があるかどうか）については何も保証していません。 木を見て森を見失わないようにしましょう。

C++ にも参照があるのではないですか？

はい。 しかし、その参照はメモリ安全ではありません。

C++ の参照は任意の値に設定できないため、生ポインターよりも正しく使いやすいものです。 しかし、それでも可変エイリアスを許します。 それは検証と並行コードの両方にとって問題です。

また、有効性も強制しません。 C++ では、すでに「存在しなくなった」オブジェクト、つまり解放済みのオブジェクトへの参照を誤って使用することがあります。これはバグであり、潜在的には脆弱性です。Rust はこれを防ぎます。

私たちの主張を検証する

セキュリティが要件であるときには、「信頼せよ、されど検証せよ」という考え方を採用するとよいでしょう。 では、Rust の解析が実際にどのように働くかを見てみましょう。 次の有効なプログラムを考えてください。

fn incr(a: &mut isize, b: &isize) {
    *a += *b;
}

fn main() {
    // 整数
    let mut val = 40;
    let step = 2;

    // 整数への参照
    let a = &mut val;
    let b = &step;

    println!("Before incr: a == {}, b == {}", a, b);
    incr(a, b);
    println!("After incr: a == {}, b == {}", a, b);
}

前のセクションの最初の図の組を思い出してください。そこでは、エイリアシングも無効なポインターもありませんでした。 このプログラムは次のように出力します。

Before incr: a == 40, b == 2
After incr: a == 42, b == 2

呼び出しの後、私たちはその2つ目の「良い」図に到達しました。

この関数は期待どおりに動作します。 フォーマット指定子 {} が、整数そのものを出力するために逆参照を行ってくれる点に注目してください。

Rust の参照では、無効なポインタを生成する方法はありません。 そのため、それは試すことすらできません。 では、参照にエイリアスを作ろうとして、前のセクションで見た問題のあるエイリアシング図を作り出そうとするとどうなるでしょうか？

fn incr(a: &mut isize, b: &isize) {
    *a += *b;
}

fn main() {
     // 整数
    let mut val = 40;
    let step = 2;

    // 整数 `val` へのエイリアス参照
    let a = &mut val;
    let b = a;

    println!("Before incr: a == {}, b == {}", a, b);
    incr(a, b);
    println!("After incr: a == {}, b == {}", a, b);
}

このプログラムは実行されることはありません。代わりに、コンパイル時エラーが発生します。

error[E0382]: borrow of moved value: `a`
  --> src/main.rs:16:10
   |
11 |     let a = &mut val;
   |         - move occurs because `a` has type `&mut isize`, which does not implement the `Copy` trait
12 |     let b = a;
   |             - value moved here
...
16 |     incr(a, b);
   |          ^ value borrowed here after move

For more information about this error, try `rustc --explain E0382

このエラーはおそらく混乱を招くでしょう。 コンパイラは、一意な可変参照を複製することはできないと指摘しています。 それは、特に並行プログラムでは潜在的に危険なエイリアスになります。 このエラーは、第3章で「所有権」と「トレイト」を扱った後で、より理解しやすくなるでしょう。

話がうますぎるのでは？

ここまでで、Rust のコンパイラが可変エイリアシングを素早く効果的に検出する様子を見てきました。 Rust が C のようなメモリ制御を提供するなら、コンパイラ内部の解析も、これまで説明した points-to 解析と同じ根本的な障害に突き当たるはずではないでしょうか？

意外かもしれませんが、答えはノーです。 ここには、互いに関連する3つの要因があります。

• 型システムによるサポート: Rust の内部解析器は、言語そのものとの直接的な統合という土台、つまり型システムの上に構築されています。この型システムは「アフィン型」⁸の一種を実装しており、任意の型キャストを許可しません。

  • 弱い型付けの言語（C など）に対して静的解析を行っても、これに匹敵する共同設計上の利点はありません。Rust コンパイラは、C 系のコンパイラや解析ツールでは証明できない性質を、設計上証明できます。

• 実行時サポート: Rust のメモリ安全性の保証がすべてコンパイル時に強制されるわけではありません。一部のチェックは実行時に行う必要があるため、Rust コンパイラはその目的のために追加のコードを挿入します。それらのチェックが失敗すると、Rust プログラムは終了する可能性があります。

  • メモリが破壊されたり悪用されたりしたプログラムが激しく死ぬよりは、正常な終了のほうが望ましいものの、理想的ではありません。この本の後半では、実行時の「パニック」に対する堅牢性テストを扱います。

• 強い制約: 安全な Rust プログラムは、一連の特別なルールに従わなければなりません。mut キーワードには規定があります。型システムの機能であるこれらの制約により、一部のアルゴリズムは Rust で表現しにくくなります。少なくとも、捉え直しなしには難しいのです。

  • これらの制約の中で最も悪名高いものは、参照は共有（&T）または可変（&mut T）のどちらかにはなれるが、両方にはなれない、というものです。これは特定の種類のデータ構造にとって障害になります。この本の前半では、その解決策を探っていきます。

そもそも型システムとは？

型システムは静的解析の一般的な形態であり、特定の種類の実行時エラーを排除できます。 この話題についての短い補足は、付録の 基礎: 型システム セクションを参照してください。

まとめ

Rust のコンパイラは、メモリ安全性の性質を検証するためのファーストパーティの静的解析を提供します。 これは、Rust プログラムをビルドするたびに得られる、無料で即時の、そして大きな保証価値の追加です。

高価な製品（たとえば複雑なコード解析ツール）や、スケールしにくい専門家プロセス（たとえば熟練したセキュリティエンジニアによるベストエフォートのコードレビュー）に頼る必要はありません。 それは［ほとんどの場合］「ただ動く」のです。 保証は反復可能なデフォルトになります。

これらの保証は主に、「所有権」という新しい概念を導入する Rust の型システムの産物です。 その仕組みはメモリモデルとエイリアシングの複雑さを克服し、特定の正しさの概念を証明できるようにします。 所有権がどのように機能するかについては、第3章で詳しく掘り下げます。

動的解析に進み、最初の Rust プログラムを書き始めましょう。

形式検証のための基礎

Rust の型システムは、形式検証研究に重要な意味を持ちます。 具体的には、共有された可変状態が存在しないため、この言語は一階述語論理⁹を使う検証技法に適しています。

一階述語論理は、学部課程の離散数学の授業で教えられます。 そうした授業は、コンピュータサイエンスのカリキュラムでは一般的です。 これは、実務エンジニアが Rust の演繹的検証ツールを使うために、分離論理（より新しく高度なトピック）を学ぶ必要がないかもしれない、ということを意味します。

第11章では、演繹的検証の初期プロトタイプを試します。 Rust の検証は、活発な学術研究の領域です。

1. 文脈の中のソフトウェア、Zach Tellman とともに。Zach Tellman、Adam Gordon Bell（2019）。 ↩

2. Memory Mapped Input/Output（MMIO）は、遠く離れた、一見ランダムなメモリ領域に大量のマジックバイトを書き込む必要がある文脈です。意外かもしれませんが、それはハードウェア周辺機器を制御する主要な方法の1つです。「データシート」（製造元が書いた公式のハードウェアマニュアル）には、どの特定のメモリアドレスにどのマジックバイトを書き込むべきかが記されています。これは、まさに生ポインタが必要で、危険など知ったことか、という類のものです！¹⁰。 ↩

3. Rust プログラミング言語の理解と進化（博士論文）。Ralf Jung（2020）。 ↩

4. Rust の Unsafe が機能する理由。jam1garner（2020）。 ↩

5. Pin における不健全性。comex（2019）。Rust コンパイラは人間によって書かれ、保守されていることを忘れないでください。ここにリンクした Pin の問題のように、時にはバグもあります。繰り返しますが、絶対的なセキュリティなど存在しません。Rust の型システムの形式検証は、頻繁に変更されるコンパイラのコードベース全体にバグがないことの検証を意味するわけではありません！ ↩

6. totally_safe_transmuteの行ごとの解説. William Woodruff (2021). このブログ記事では、transmutation（ある型のビットを別の型として再解釈すること）のための型破りなトリックを詳しく説明しています。このトリックでは、プログラムがOS機能を使って、Rustコンパイラが想定しておらず、想定しようもない方法で、実行時に自身のコードを変更します。そのため、コンパイラにとっては「安全」ですが、実際には極めて安全ではありません。これはRustの安全性保証が破られているという意味ではなく、型システムがプログラムの実行環境のあらゆる側面をモデル化できるわけではない、というだけです。また、そうすべきでもありません。現実世界のほとんどのプログラムは、実行時にメモリ上の自身の表現を書き換えたりしません。 ↩

7. コンピュータ科学者がプログラミング言語 Rust の安全性主張を証明。Saarland University（2021）。Rust の形式検証は、現在の成功と継続中の取り組みの両方を伴う研究課題であることに注意してください。 ↩

8. アフィン型システム. Wikipedia (Accessed 2022). ↩

9. RustHorn: CHCベースのRustプログラム検証. Yusuke Matsushita, Takeshi Tsukada, Naoki Kobayashi (2020). ↩

10. tock-registers. Tock Project Developers (2021). このプロジェクトは、カスタマイズ可能な型の形で安全なMMIO抽象化を提供します。生ポインタの代替として確認する価値があります。 ↩

動的保証（全3回の1）

静的解析は取り組むのが難しいトピックになり得ます。それは、日々の開発の現実から切り離されているように見える理論と証明の世界の氷山の一角です。 しかし、コンパイラのユーザーである私たちは、実装の詳細をすべて理解しなくても型システムの恩恵を受けています。

それに比べると、動的解析は楽しく、身近に感じられる相方です。 独自の静的解析を実装する開発者はほとんどいません。 ほとんどのプロの開発者はユニットテストを書きます。これは、プログラムの一部を意味のある方法で実行する小さな動的解析です。

動的解析は概念的には理解しやすいものです。具体的な入力でプログラムを実行し、何が起こるかを観察することで、そのプログラムについて学びます。

• 長所: 実際のプログラムを現実世界で実行したものなので、各実行結果を信頼できます。偽陽性はありません¹。

• 短所: 一度に観察できるのは1回の実行だけなので、データポイントの集合から繰り返しサンプリングすることで確信を積み上げていきます。しかし、完全な集合はたいてい巨大であり、私たちのサンプルはごくわずかです。そのため、一般的な結論を導くことはできません。

  • 動的解析は、1つ以上のバグの存在を証明できます。しかし、いかなる種類のバグの不在も証明することはできません。

プログラムを実行すると何が起こるのでしょうか？

ハードウェアとソフトウェアのコンポーネントのオーケストラが、複雑な方法でタスクを実行し、相互作用します。 1万フィート上空から眺めると、おおよそ次のようになります。

ローダーがプログラムのインスタンスをメモリにコピーし、そのための隔離された環境をセットアップして、「プロセスを生成」します。 プロセスが実行中で、ディスクへの書き込みやネットワークデータの読み取りを行いたい場合、オペレーティングシステム（OS）の協力を引き出します。 そのOSは、物理ディスクドライブやネットワークインターフェイスカードのようなハードウェアへのアクセスを管理します。 比較的小さな状態機械である*中央処理装置（CPU）*が、あなたのプログラム、何百もの他のプログラム、そしてOS自体の実行を高速に切り替えることで、一連のイベント全体を駆動します。

動的解析は、*テスト対象プログラム（Program Under Test: PUT）*に便乗する小さなプログラムです。 実行中、あるいは実行の前後にPUTへ「フック」し、「ライブイベント」を記録します。 たとえば、デバッガーは実行中の特定の時点における変数の現在値を読み取れます。 ユニットテストは、特定のパラメーターで実行された特定の関数の戻り値を確認できます。

Rustで暗号を少し書いてみましょう！

現実的には、読者のうち決して少なくない割合の人が、この第2章を越えて読み進めないかもしれません。 現実の優先事項は変わりますし、新しい言語と新しいスキルセットを学び、それを最後までやり遂げるのは大変なタスクです。

だからこそ、あなたには今すぐ興味深いRustプログラムを書いてもらいます。 実際に動くもの、実行できるものを作りましょう。 コマンドラインツールのエンドユーザーとしても、セキュリティ上重要なライブラリを検証するテスターとしても使えるものです。

これから、小さいながらもモジュール化されたプログラムを書きます。 それには2つの部分があります。

1. 単一暗号の暗号ライブラリ: 有名だが時代遅れのストリーム暗号であるRC4を、ゼロから実装した、組み込み向けにも適した実装です。扱いの難しいRustコードを書くための独立した短期集中講座だと考えてください。

2. コマンドラインインターフェイス: あなたの暗号ライブラリを使って、コンピューター上のファイルを暗号化および復号する方法です。引数解析とファイルI/Oを実行できるようになることは、どんな新しい言語でも、実用的なプロジェクトへの扉を開きます。

さて、暗号は正しく実装するのが非常に難しいことで有名です。 そしてRustコンパイラは、どれほど強力であっても、特定のアルゴリズムの実装の正しさを静的に推論することはできません。ストリーム暗号であれ、それ以外であれ同じです。 ここで動的解析の出番です。

• 既知の正しいRC4実装との入力出力の等価性を示すユニットテストを書きます。

• 動的解析がどこで失敗するのかを理解するために、ライブラリへ単純なバックドアを挿入します。

ストリーム暗号とは何でしょうか？

この用語を初めて見る場合、または簡単に復習したい場合は、先に進む前に付録の「基礎: ストリーム暗号」セクションを読んでください。 次のセクションの暗号コードを理解するために必要な背景を簡潔に説明しています。

モジュール化されたプロジェクトのセットアップ

第1章の終わりでセットアップした開発環境にログインし、ここから先は手を動かしながら進めてください。 以下を流し読みするだけでなく、実際にやって学びましょう！

まず、Rustツールチェーンが正しくインストールされていることを確認します。 次のコマンドを実行すると何が起こるでしょうか？

rustup doc --std

WebブラウザーでRust標準ライブラリのドキュメントが開くはずです。 このコマンドは覚えておくと便利です。 もし飛行機の中でエアギャップされた安全な施設でコーディングしたことがあるなら、オフラインでアクセスできるドキュメントが必要になるかもしれません。

次に、Rustのパッケージマネージャーであるcargoを使って、「ワークスペース」²を作成します。 ワークスペースは、独立したモジュール（Rustの用語ではクレートと呼ばれます）で構成されるプログラムを整理するための便利な方法です。

• 各クレートは、それ自体が独立した「プロジェクト」です。IDEが作成するもののようなものです。

• ワークスペースでは、2つ以上のクレートが単一のビルドディレクトリを共有できます。これにより、共有依存関係のコンパイル時間を節約できます。

• クレートは、ワークスペース内の同等の仲間（同じワークスペース内にあるが別のサブディレクトリにある他のクレート）の公開APIを呼び出せます。

この章で書くコードはかなり短いものになります（200行未満）。 しかし、より大きなプロジェクトでは、ワークスペースがモジュール性を助けます。 モジュール化されたコード構成は、複雑さを抑えるのに役立ちます（これについては第3章で詳しく説明します）。

まず、暗号ライブラリとそのコマンドラインインターフェイスの両方を収める最上位ディレクトリを作成します。 crypto_toolと呼ぶことにしましょう。

mkdir crypto_tool

次に、cargoを使って2つのクレートのスケルトンを生成します。

1. rc4という名前のライブラリ（共有オブジェクト）クレート。

2. rcliという名前のバイナリ（実行可能）クレート（“RC4 CLI“を疑わしく短縮したもの）。

rcliバイナリは、rc4ライブラリのAPIに依存します。 既存の独立した暗号ライブラリを使用する現実世界のツールと同じです。

両方のクレートの定型コードを生成するには、次のようにします。

cargo new crypto_tool/rc4 --lib
cargo new crypto_tool/rcli

--libフラグは、cargoにライブラリクレートを特に作成するよう伝える点に注意してください。 フラグが指定されていない場合、mainメソッドを持つ実行可能バイナリがデフォルトです（ただし、明示したい場合は--binを使うこともできます）。

バイナリとライブラリの違いは何ですか？

バイナリは、直接実行できるスタンドアロンプログラムです。 以下の tree コマンドは、対応するバイナリプログラムを探して実行するようシェルに指示します。

ライブラリには再利用可能なコードが含まれており、通常はバイナリや他のライブラリから呼び出せる API です。 tree がコンソールに出力を表示するとき、C の標準ライブラリ内の API である printf を呼び出します。

面白い事実があります。Linux の ELF や Windows の PE のようなファイル形式では、ライブラリとバイナリの違いはファイルヘッダー（ローダーが理解するメタデータ）内のわずか 1 バイトだけです。 CPU から見れば、どちらも単なるプログラムです！

現時点では、cargo は 2 つのクレート（rc4 と rcli）が関連していることを知りません。 今のところ、それらはたまたま隣接するディレクトリに存在しているだけです。 crypto_tool ディレクトリに新しい Cargo.toml ファイルを作成して、cargo に状況を把握させておきましょう。

touch Cargo.toml

この新しく作成したファイルを好みのエディターで開き、rc4 と rcli が同じワークスペースの一部であることを cargo に知らせるために、次の内容を入力します。

[workspace]
members = [
    "rc4",
    "rcli"
]

Linux コマンドの tree を実行すると、次のようなファイルとディレクトリの構成が表示されるはずです。

.
└── crypto_tool
    ├── Cargo.toml
    ├── rc4
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    └── rcli
        ├── Cargo.toml
        └── src
            └── main.rs

5 directories, 5 files

.rs は Rust ソースファイルの拡張子です。 2 つの .rs ファイル（main.rs と lib.rs）が、これからコードを書く場所です。

Cargo.toml ファイルはプロジェクトマニフェスト³であり、Rust のビルドシステムの設定です。 他の 2 つは cargo new を実行したときに自動的に作成されたことに注目してください。 少し時間を取って、それらの内容を確認してください。

rcli は rc4 ライブラリに依存するため、cargo はコンパイル時にライブラリコードを見つける方法を必要とします。 その Cargo.toml ファイルの [dependencies] タグの下にエントリを追加する必要があります。 rcli/Cargo.toml を開き、以下のように最後の行を追記します。

[package]
name = "rcli"
version = "0.1.0"
edition = "2021"

# キーとその定義の詳細については https://doc.rust-lang.org/cargo/reference/manifest.html を参照してください

[dependencies]
rc4 = { path = "../rc4" }

ワークスペースの準備が整っていることを確認するには、crypto_tool ディレクトリから cargo build を実行します。 以下のような出力が表示され、rc4 と rcli の両方が正常にコンパイルされたことが示されるはずです。

   Compiling rcli v0.1.0 (/home/tb/proj/high-assurance-rust/code_snippets/chp2/crypto_tool/rcli)
   Compiling rc4 v0.1.0 (/home/tb/proj/high-assurance-rust/code_snippets/chp2/crypto_tool/rc4)
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s

定型的な準備が片付いたので、組み込み環境に適した RC4 ライブラリを書き始める準備ができました！

次のセクションの詳細をすべて理解する必要がありますか？

いいえ。 次のセクションでは、Rust の構文と暗号技術の概念の両方に触れます。 先に進むために、細部まで完全に理解する必要はありません。

• Rust の見慣れない構文は、特に第 3 章以降、読み進めるにつれて身についていきます。

• 暗号技術はこの本の主題ではありません。この章で開発しているサンプルプログラムの文脈として、大まかな内容を把握すれば十分です。

  • 必要に応じて、対応する付録セクションを確認することを忘れないでください。

1. 一般的に言えば、動的解析には偽陽性はありません。ただし、テスト固有の例外は存在します。たとえば、クラッシュを引き起こす入力を見つけるために単一の関数をファジング（ストレステスト）しているとします。クラッシュを見つけるかもしれませんが、実際にはプログラム全体が、クラッシュを引き起こす入力をテスト対象関数に渡す前にサニタイズ（正規化または拒否）している可能性があります。この場合、そのクラッシュはより大きなプログラムの文脈では実際には再現できないかもしれません。 ↩

2. ワークスペース。The Cargo Book（2022 年アクセス）。 ↩

3. マニフェスト形式。The Cargo Book（2022 年アクセス）。 ↩

動的保証（全3回中2回）

あらゆるストリーム暗号と同様に、RC4はキーストリームを生成し、それを平文とビット単位でXORして暗号文を作成する必要があります。これが暗号化の仕組みです。

• キーストリーム - 再現可能だがランダムと区別できないデータ。

• 平文 - 暗号化されていないデータ。

• 暗号文 - 暗号化されたデータ。

キーストリーム生成は、暗号状態を表すバッファを使って実装されます。 機械的には、RC4の暗号状態はsという名前の256バイト配列であり、iとjという2つの変数でインデックス付けされます。 最初のステップは、この絶えず変化する状態と、そのインデックスの現在値を格納する構造体を作成することです。 crypto_tool/rc4/src/lib.rsの先頭に以下を追加します。

#![cfg_attr(not(test), no_std)]
#![forbid(unsafe_code)]

#[derive(Debug)]
pub struct Rc4 {
    s: [u8; 256],
    i: u8,
    j: u8,
}

• 最初の2行は属性です。これらはコンパイラとやり取りし、プロジェクトを設定します。

• #![cfg_attr(not(test), no_std)]は条件付き属性です。クレート全体に適用され、testビルドでない限り、このライブラリは実行されるシステムについて何も仮定しないことをコンパイラに知らせます。

  • no_stdは、おおまかに「標準ライブラリやランタイムサポートが利用可能であることに依存しない」という意味です。これにより利用できるのはRustのコア機能の集合に制限されますが、ファームウェア、ブートローダー、カーネルなどの組み込みユースケース向けにコードをポータブルにできます。#![no_std]については第4章でより詳しく説明します。

• #![forbid(unsafe_code)]は無条件属性です。これもクレート全体に適用され、ライブラリにunsafeコードブロックがないことを保証するようコンパイラに指示します。これにより、後でリファクタリングしたり新機能を追加したりしても、コードはRustのメモリ安全性保証を最大限に活用できます。

  • 本書全体を通じてunsafeについて説明しますが、メインプロジェクトではこのキーワードを使用しません。

• #[derive(Debug)]は、トレイト（共有される振る舞いの定義。第3章で説明します）と呼ばれるもののためのderiveマクロです。マクロは追加のコードを生成します。マクロを書くことは高度なトピックですが、初心者でも既存のマクロを活用できます¹。

  • #[derive(Debug)]がRc4構造体の上に置かれていることに注目してください。これはこの構造体にのみ適用され、その内容をコンソールにきれいに表示する方法をコンパイラに伝えます²。このマクロを使うことで、テストビルドでストリーム暗号を視覚的にデバッグしやすくなります。

• Rc4構造体は、上記コードで最も重要な部分です。伝統的な意味でのオブジェクトではありませんが³、この構造体はプライベートデータをカプセル化し、次にそのデータを操作するメソッドを定義します。Rc4の3つのフィールドは次のとおりです。

  • s: 暗号状態。256バイトの配列（符号なし8ビット整数、したがってu8）。

  • i: キーストリーム生成のための「インクリメントされる」インデックス。

  • j: キーストリーム生成のための「ジャンプする」インデックス。

これで、RC4のロジックの2つの部分、KSAとPRGAを実装する準備が整いました。

警告！RC4は安全ではありません。

実際のプロジェクトでは、よく監査された、モダンで十分にテストされた暗号の実装を選択する必要があります。 この章の例としてRC4を選んだのは、実装が比較的簡単だからだということを忘れないでください。 RC4はプロフェッショナルなプロジェクトには適していません。

1. 鍵スケジューリングアルゴリズム（KSA）

RC4のKSAステップの目的は、可変長（40〜2,048ビット）の秘密鍵の影響を受ける置換を計算して、暗号状態配列を初期化することです。

このロジックはRc4のコンストラクタに置くのが最善です。 そうすれば、ライブラリのユーザーはデータを暗号化する前に特別な初期化関数を呼び出すことを覚えておく必要がありません。 コンストラクタから返される暗号インスタンスは、すでに初期化されています。

関数関連の用語

このセクションでは2つの専門用語を使用します。 これらの概念はRustに固有のものではありませんが、Rustプログラムでは用語に特定の意味があります:⁴

• 関連関数: 構造体に定義されているが、最初のパラメータとして&self（構造体のインスタンスへの参照）を取らない関数です。構造体のフィールドを読み書きしません。

• メソッド: 構造体に定義され、最初のパラメータとして&selfまたは&mut selfを取る関数です。構造体の特定のインスタンス上のフィールドを読み書きします。

慣例として、Rustのコンストラクタは、構築される構造体のインスタンスを返す、newという名前の関連関数（selfパラメータなし）です。

Rc4構造体定義のすぐ下に、KSAを実行するものを追加しましょう。 同じ名前の構造体に結び付けるために、impl Rc4ブロックの中でnewを定義していることに注目してください。

impl Rc4 {
    /// Init a new Rc4 stream cipher instance
    pub fn new(key: &[u8]) -> Self {
        // Verify valid key length (40 to 2048 bits)
        assert!(5 <= key.len() && key.len() <= 256);

        // Zero-init our struct
        let mut rc4 = Rc4 {
            s: [0; 256],
            i: 0,
            j: 0,
        };

        // Cipher state identity permutation
        for (i, b) in rc4.s.iter_mut().enumerate() {
            // s[i] = i
            *b = i as u8;
        }

        // Process for 256 iterations, get starting cipher state permutation
        let mut j: u8 = 0;
        for i in 0..256 {
            // j = (j + s[i] + key[i % key_len]) % 256
            j = j.wrapping_add(rc4.s[i]).wrapping_add(key[i % key.len()]);

            // Swap values of s[i] and s[j]
            rc4.s.swap(i, j as usize);
        }

        // Return our initialized Rc4
        rc4
    }
}

上記のコードを見ると、少し不安になるかもしれません。 それで大丈夫です。 新しい言語を学ぶということは、完全には理解していないコードに目を凝らすことを伴います。 そして、それはたいていあまり良い気分ではありません。

さらに悪いことに、暗号コードは、実装言語にかかわらず、それ自体が独特なものです。 踏み込んで、理解を試みましょう。

• new は単一のパラメータ key を取ります。これはバイトスライスへの参照です。このシグネチャにより、鍵データの受け渡しが効率的⁵かつ柔軟⁶になります。スライスについては第3章で扱います。

• 別のマクロである assert! 文は、API のユーザーが有効な長さの鍵を提供することを保証します。そうでない場合、プログラムはこの行で終了します。これはエラーを処理するには強硬な方法です。他の選択肢については後で説明します。

• let mut rc4 = ... は、すべてのフィールドがゼロ初期化された Rc4 構造体の可変インスタンスを作成します。Rust では、変数はデフォルトで不変です。しかし、ここでは暗号の状態（s 配列）をセットアップするため、mut キーワードが必要です。

• 次のコード片である for ループの恒等置換⁷は、s[0] = 0, s[1] = 1, s[2] = 2, ..., s[255] = 255 を設定する凝った書き方にすぎません。これはイテレータを使用しています。第10章で独自のイテレータを実装するので、今はこの構文について詳しく立ち入らないことにしましょう。

• 続く for ループは、暗号状態 s をさらに置換します。指摘しておく価値のある詳細が3つあります。

  • 暗号コードでは、加算演算子（+）ではなく wrapping_add 関数を使用する必要があります。これは、整数オーバーフロー（第3章で説明します）によって剰余算術⁸を模倣したいからです。

  • 3つ目の変数（おそらく temp という名前）を使って2つの変数を入れ替えたことはありますか？答えが「うわ、何百回もあるよ」なら、Rust では swap が配列の組み込みメソッドであることのありがたみが分かるでしょう。

  • Rust では、インデックスは常にレジスタ幅の符号なし整数です。そのため、swap の呼び出しでは、as キーワードを使って j（取るに足らない u8）を usize に昇格させます。このちょっとした詳細は「安全なキャスト」⁹だと考えてください。

• new 関数の最後の行は、初期化済みの Rc4 構造体インスタンスを返します。Rust の関数では、何らかの理由で早期に返したい場合（たとえば関数本体の途中）を除き、return キーワードは不要です。

  • 関数の戻り値の型（-> の直後に指定されているもの）は Self です。new は impl Rc4 ブロック内にあるため、これは Rc4 構造体のインスタンスを返すことの省略形です。

置換の1ラウンドを可視化すると、この概念がより具体的になるかもしれません。 各ループ反復で i と j が変化し（j は鍵の影響を受けます）、rc4.s.swap(i, j as usize) は s 内の2つの値を入れ替えるだけです。

2. 疑似乱数生成アルゴリズム（PRGA）

new 関数は Rc4 暗号のインスタンスを作成して初期化します。 キーストリームを生成するには、Rc4 インスタンスを使用する別の関数が必要です。 キーストリームが得られれば、それを使ってデータを暗号化できます。

prga_next はキーストリーム生成関数であり、呼び出されるたびに1バイトのキーストリームを出力します。 これを new 関数の直後、同じ impl Rc4 ブロック内に追加します。

new 関連関数とは異なり、prga_next はメソッドです。 メソッドは常に、呼び出し対象である構造体のインスタンス self への参照を第1パラメータとして取ります。

impl Rc4 {
    // ..new() の定義は省略..

    /// Output the next byte of the keystream
    pub fn prga_next(&mut self) -> u8 {
        // i = (i + 1) mod 256
        self.i = self.i.wrapping_add(1);

        // j = (j + s[i]) mod 256
        self.j = self.j.wrapping_add(self.s[self.i as usize]);

        // Swap values of s[i] and s[j]
        self.s.swap(self.i as usize, self.j as usize);

        // k = s[(s[i] + s[j]) mod 256]
        self.s[(self.s[self.i as usize].wrapping_add(self.s[self.j as usize])) as usize]
    }
}

この関数は new 関数と似た操作を行うため、詳細に見ていく必要はありません。 私たちが関心を持っているのは Rust の雰囲気をつかむことであり、RC4 の設計が要求する具体的な操作ではありません。 ただし、指摘しておく価値のある詳細が1つあります。

• prga_next の唯一のパラメータは &mut self で、これは呼び出し対象となる Rc4 構造体への可変参照です。この関数は Rc4 構造体に変更を加えるため、ここでも mut キーワードが必要です。具体的には、インデックス i と j に書き込み、暗号状態バッファ s 内のバイトを入れ替えます。

余談ですが、k を出力するその行は、次のように可視化できます。¹⁰

3. 暗号化/復号

古典的な柔軟なインターフェイス

各 prga_next 出力バイト（キーストリーム）を平文の各バイトと XOR することで、暗号化を実装します。 XOR は可逆なので、同じ関数は復号にも使えます！

impl Rc4 {
    // ..new() の定義は省略..

    /// Stateful, in-place en/decryption (current keystream XORed with data).
    /// Use if plaintext/ciphertext is transmitted in chunks.
    pub fn apply_keystream(&mut self, data: &mut [u8]) {
        for b_ptr in data {
            *b_ptr ^= self.prga_next();
        }
    }

    // ..prga_next() の定義は省略..
}

メソッド内で暗号化を実装すると、柔軟性が最大化されます。データを［長さが可変かもしれない］チャンクとして受け取る場合、Rc4 の単一インスタンスで、次のように複数のチャンクにまたがる「継続的な」暗号化を実行できます（以下は API 使用例であり、Rc4 実装の一部ではありません）。

let key = [0x1, 0x2, 0x3, 0x4, 0x5];

let msg_1 = [0x48, 0x65, 0x6c, 0x6c, 0x6f]; // "Hello"
let msg_2 = [0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x21]; // " World!"

// インプレースで暗号化
let mut rc4 = Rc4::new(&key);
rc4.apply_keystream(&mut msg_1);
rc4.apply_keystream(&mut msg_2);

// インプレースで復号
let mut rc4 = Rc4::new(&key);
rc4.apply_keystream(&mut msg_1);
rc4.apply_keystream(&mut msg_2);

現実世界のストリーム暗号ライブラリの多くは、このような API を使用しています。 しかし、これには微妙な複雑さが伴います。rc4 は状態を持っており、復号の前に new で再構築しなければなりません。 さらに、apply_keystream へのパラメータの順序も重要です。上記で誤って rc4.apply_keystream(&mut msg_1) より前に rc4.apply_keystream(&mut msg_2) を呼び出すと、復号結果は不正になります。

一般的なケースをより簡単にする

すべてのデータが一度にメモリ上にある限り、関連関数内で暗号化を実装すると、より単純なインターフェイスを提供できます。 これはかなり頻繁に当てはまるかもしれません。 これは実際には、呼び出し元から状態を隠す単なるラッパーであることに注目してください。

impl Rc4 {
    // ..new() の定義は省略..

    // ..apply_keystream() の定義は省略..

    /// Stateless, in-place en/decryption (keystream XORed with data).
    /// Use if entire plaintext/ciphertext is in-memory at once.
    pub fn apply_keystream_static(key: &[u8], data: &mut [u8]) {
        let mut rc4 = Rc4::new(key);
        rc4.apply_keystream(data);
    }

    // ..prga_next() の定義は省略..
}

これで、Rc4 インスタンスの状態を気にすることなく、単一のメソッド呼び出しで暗号化/復号できます（API 使用例は以下のとおりです）。

let key = [0x1, 0x2, 0x3, 0x4, 0x5];

let msg = [
    0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f,
    0x72, 0x6c, 0x64, 0x21,
]; // "Hello World!"

// インプレースで暗号化
Rc4::apply_keystream_static(&key, &mut msg);

// インプレースで復号
Rc4::apply_keystream_static(&key, &mut msg);

2つの暗号化/復号関数が完成したので、実装は完了しました。 検証の時間です。 暗号ソフトウェアは本当に正しくなければならないため、ここで止まることはできません。 このコードを徹底的に試してみましょう！

暗号化と復号は、どうして同じ操作になり得るのでしょうか？

要するに、XOR は可逆であり、かつキーストリームの性質により予測不能だからです。

• まず、cipher_text = plain_text ^ key_stream（暗号化）です。

• 次に、plain_text = cipher_text ^ key_stream（復号）です。

• キーストリームは、平文内の任意のビットを、あたかも 50/50 のランダムな確率であるかのように反転できます。

より数学的に原理に基づいた扱いについては、Paar と Pelzl の Understanding Cryptography¹¹ の 32 ページにある証明をおすすめします。 大学の教科書ではありますが、形式的な記述は軽量で正確です。 暗号学の分野への優れた入門書です。 さらに、この本には無料の動画講義¹²も付属しています。

1. C のマクロとは異なり、Rust のマクロは衛生的です。つまり、識別子を捕捉して微妙な問題を引き起こすことはありません。これが、Rust のマクロが非常に使いやすい理由の一部です。実際、println! はマクロです。したがって、第1章の終わりで「Hello world!」プログラムを実行したとき、あなたはすでにマクロを使っていたことになります。 ↩

2. トレイト std::fmt::Debug。The Rust Team（2022年アクセス）。 ↩

3. Rust では、共有される振る舞いはオブジェクト指向の継承ではなく、トレイト合成によって定義されます。C++ や Java のような「クラス階層」はありません。トレイトについては第3章で扱います。 ↩

4. 技術的には、Rust リファレンス¹³によると、「関連関数は型に関連付けられた関数」であり、「最初のパラメーターの名前が self である関連関数はメソッドと呼ばれます…」。しかし、それはかなり細部に踏み込んだ話です。このセクションでは明確さのために、関連関数とメソッドを別個のものとして扱います。 ↩

5. スライス参照は「ファットポインター」（ポインターと要素数のタプル）であり、データをコピーせずに可変長データを渡すことを可能にします（ポインターについて最初に話したときの「参照渡し」を思い出してください）。 ↩

6. スライスは柔軟です。なぜなら、異なる種類のコレクション（たとえば、固定長配列や動的サイズのベクター）をスライスを通して「見る」ことができるからです。そのため、慣用的な Rust コードではスライスによく出会うことになります。 ↩

7. 単位元と逆元。Wikipedia（2022年アクセス）。 ↩

8. 剰余算術。Wikipedia（2022年アクセス）。 ↩

9. Rust のキャストにはベストプラクティスがあります。具体的には、型間の失敗しない変換にはトレイト From と Into を使い、失敗する可能性のある変換には TryFrom と TryInto を使います。このトピックについては後で詳しく説明します。 ↩

10. RC4。Wikipedia（2022年アクセス）。 ↩

11. [個人的なお気に入り] Understanding Cryptography。Christof Paar、Jan Pelzl（2009）。 ↩

12. オンライン暗号学コース。Christof Paar、Jan Pelzl（2009）。 ↩

13. The Rust Reference: 関連項目。The Rust Team（2021）。 ↩

動的保証（3/3）

crypto_tool/rc4/src/lib.rs の末尾に小さなモジュール（mod キーワードのスコープ）があることに気づいたかもしれません。

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        let result = 2 + 2;
        assert_eq!(result, 4);
    }
}

これはユニットテストのボイラープレートで、以前に cargo new crypto_tool/rc4 --lib を実行したときに生成されたものです。 これから、これを独自のユニットテストに置き換えます。

最初に書くテストは、基本的には「健全性チェック」です。 最低限、私たちのライブラリは平文を別のもの（おそらく暗号化された形式）に変換し、それを元に戻せるべきです。 このテストはまさにそれを確認します。

#[cfg(test)]
mod tests {
    use super::Rc4;

    #[test]
    fn sanity_check_static_api() {
        #[rustfmt::skip]
        let key: [u8; 16] = [
            0x4b, 0x8e, 0x29, 0x87, 0x80, 0x95, 0x96, 0xa3,
            0xbb, 0x23, 0x82, 0x49, 0x9f, 0x1c, 0xe7, 0xc2,
        ];

        #[rustfmt::skip]
        let plaintext = [
            0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f,
            0x72, 0x6c, 0x64, 0x21,
        ]; // "Hello World!"

        let mut msg: [u8; 12] = plaintext.clone();

        println!(
            "Plaintext (initial): {}",
            String::from_utf8(msg.to_vec()).unwrap()
        );

        // Encrypt in-place
        Rc4::apply_keystream_static(&key, &mut msg);
        assert_ne!(msg, plaintext);

        println!("Ciphertext: {:x?}", msg);

        // Decrypt in-place
        Rc4::apply_keystream_static(&key, &mut msg);
        assert_eq!(msg, plaintext);

        println!(
            "Plaintext (decrypted): {}",
            String::from_utf8(msg.to_vec()).unwrap()
        );
    }
}

最初の平文を出力し、apply_keystream_static を使ってそれを暗号化して結果を出力し、同様に復号して結果を出力します。

• key は、テスト目的で任意に選んだランダムな 16 バイトの鍵です。

• msg は、ASCII¹ 文字列 “Hello World!” の生バイトです。

• String::from_utf8(msg.to_vec()).unwrap() は、生バイトを出力可能な文字列に変換します。

  • これは失敗しうる操作です（入力として出力不可能なバイトを渡すこともできたからです！）そのため、「操作結果」を「unwrap」する必要があります（ここでの .unwrap() は assert! のようなものです）。Result とエラーハンドリングについては第3章で説明します。

• #[rustfmt::skip] は、コードフォーマッター（cargo fmt 経由で呼び出されます）に対して、その下に現れる変数のインデントを変更しないよう指示します。このテストには直接関係ありませんが、何のためのものか気になっていたかもしれません。Rust は、大規模な複数開発者のコードベースでスタイルを一貫させるために、設定可能なコードフォーマットと lint をサポートしています。

このテストは、crypto_tool/rc4 ディレクトリから cargo test コマンドで実行できます。 デフォルトでは、cargo test はテスト結果のみを出力し、テストが失敗しない限りコンソール出力は表示しません。

println! 文を確認するには、cargo test -- --show-output を使う必要があります。 すると、出力には以下が含まれます。

---- tests::sanity_check_static_api stdout ----
Plaintext (initial): Hello World!
Ciphertext: [d0, 1c, 95, d4, 40, c7, 3c, 53, 8a, 22, d9, a1]
Plaintext (decrypted): Hello World!

この単純な動的テストにより、メッセージをスクランブルし、元に戻すことができる実行可能なプログラムがあることが示されました！

暗号文には出力不可能な文字が含まれているため、文字列として出力していない点に注意してください。 代わりに、生の 16 進バイトを表示しています。 ここで少し時間を取って、チャンク API である apply_keystream についても同様のテストを書いてみてください。

cargo test によるファーストパーティのユニットテストサポートは、C や C++ と比較した Rust の大きな強みです。 モダンな開発体験を得るために、サードパーティのテストフレームワークを学習、設定、ビルド、インポートする必要はありませんでした。

私たちの方法論は強力ですが、実際のテストはそうではありませんでした。 この「健全性チェック」は、RC4 を正しく実装したことを実際に証明するものではありません。単に、私たちのコードがデータを変換し、その変更を元に戻せることを示しているだけです。 生成された暗号文が、与えられた鍵に対して正しくない可能性があります。場合によっては、それが「解読可能」にしてしまうような形で誤っているかもしれません。つまり、攻撃者が何らかの欠陥を利用して、鍵を知らずに平文を抽出できる可能性があります。

そうではないことを確実にするには、実装を動的に検証する必要があります。 グラウンドトゥルースに対する実行可能なテストを作成します。 暗号のサイファーでは、これは多くの場合、公式の「テストベクター」（既知の正しい入出力ペア）と比較することを意味します。

動的検証

RC4 は、そう遠くない過去において、インターネットセキュリティの重要な一部でした。 かつて、インターネット上のほぼすべての TLS 接続がこのアルゴリズムを使用していたか、使用することを選択できました。 そのため、主要なインターネット標準化団体である Internet Engineering Task Force（IETF）は、プロトコル実装者が RC4 ライブラリを検証できるよう、公式のテストベクター² を公開しました。

これから、その公式ベクターを活用します！ 正当化可能な確信こそが、高保証プログラミングの特徴です。

IETF 文書² には、テストベクターデータの表が十数個含まれています。 以下はその最初のものです。

Key length: 40 bits.
key: 0x0102030405

DEC    0 HEX    0:  b2 39 63 05  f0 3d c0 27   cc c3 52 4a  0a 11 18 a8
DEC   16 HEX   10:  69 82 94 4f  18 fc 82 d5   89 c4 03 a4  7a 0d 09 19
DEC  240 HEX   f0:  28 cb 11 32  c9 6c e2 86   42 1d ca ad  b8 b6 9e ae
DEC  256 HEX  100:  1c fc f6 2b  03 ed db 64   1d 77 df cf  7f 8d 8c 93
DEC  496 HEX  1f0:  42 b7 d0 cd  d9 18 a8 a3   3d d5 17 81  c8 1f 40 41
DEC  512 HEX  200:  64 59 84 44  32 a7 da 92   3c fb 3e b4  98 06 61 f6
DEC  752 HEX  2f0:  ec 10 32 7b  de 2b ee fd   18 f9 27 76  80 45 7e 22
DEC  768 HEX  300:  eb 62 63 8d  4f 0b a1 fe   9f ca 20 e0  5b f8 ff 2b
DEC 1008 HEX  3f0:  45 12 90 48  e6 a0 ed 0b   56 b4 90 33  8f 07 8d a5
DEC 1024 HEX  400:  30 ab bc c7  c2 0b 01 60   9f 23 ee 2d  5f 6b b7 df
DEC 1520 HEX  5f0:  32 94 f7 44  d8 f9 79 05   07 e7 0f 62  e5 bb ce ea
DEC 1536 HEX  600:  d8 72 9d b4  18 82 25 9b   ee 4f 82 53  25 f5 a1 30
DEC 2032 HEX  7f0:  1e b1 4a 0c  13 b3 bf 47   fa 2a 0b a9  3a d4 5b 8b
DEC 2048 HEX  800:  cc 58 2f 8b  a9 f2 65 e2   b1 be 91 12  e9 75 d2 d7
DEC 3056 HEX  bf0:  f2 e3 0f 9b  d1 02 ec bf   75 aa ad e9  bc 35 c4 3c
DEC 3072 HEX  c00:  ec 0e 11 c4  79 dc 32 9d   c8 da 79 68  fe 96 56 81
DEC 4080 HEX  ff0:  06 83 26 a2  11 84 16 d2   1f 9d 04 b2  cd 1c a0 50
DEC 4096 HEX 1000:  ff 25 b5 89  95 99 67 07   e5 1f bd f0  8b 34 d8 75

鍵（2行目）と、有効な RC4 実装が生成するはずのキーストリームからの 18 個のサンプル（それ以降の行）が与えられています。 各サンプルは 16 バイト長で、その前にキーストリーム内のオフセット（10 進数と 16 進数の両方）が付いています。

すべての表からすべてのサンプルをテストスイートに変換することは、実際のライブラリにとっては重要ですが、今回の例では手間がかかります。 そこで、上の表の最初の 4 行だけを使います。

#[cfg(test)]
mod tests {
    use super::Rc4;

    // ..sanity_check_static_api() は省略..

    // See: https://datatracker.ietf.org/doc/html/rfc6229#section-2
    #[test]
    fn ietf_40_bit_key_first_4_vectors() {
        let key: [u8; 5] = [0x01, 0x02, 0x03, 0x04, 0x5];
        let mut out_buf: [u8; 272] = [0x0; 272];

        #[rustfmt::skip]
        let test_stream_0: [u8; 16] = [
            0xb2, 0x39, 0x63, 0x05, 0xf0, 0x3d, 0xc0, 0x27,
            0xcc, 0xc3, 0x52, 0x4a, 0x0a, 0x11, 0x18, 0xa8,
        ];

        #[rustfmt::skip]
        let test_stream_16: [u8; 16] = [
            0x69, 0x82, 0x94, 0x4f, 0x18, 0xfc, 0x82, 0xd5,
            0x89, 0xc4, 0x03, 0xa4, 0x7a, 0x0d, 0x09, 0x19,
        ];

        #[rustfmt::skip]
        let test_stream_240: [u8; 16] = [
            0x28, 0xcb, 0x11, 0x32, 0xc9, 0x6c, 0xe2, 0x86,
            0x42, 0x1d, 0xca, 0xad, 0xb8, 0xb6, 0x9e, 0xae,
        ];

        #[rustfmt::skip]
        let test_stream_256: [u8; 16] = [
            0x1c, 0xfc, 0xf6, 0x2b, 0x03, 0xed, 0xdb, 0x64,
            0x1d, 0x77, 0xdf, 0xcf, 0x7f, 0x8d, 0x8c, 0x93,
        ];

        // Remaining 14 vectors in set skipped for brevity...

        // Create an instance of the cipher
        let mut rc4 = Rc4::new(&key);

        // Output keystream
        rc4.apply_keystream(&mut out_buf);

        // Validate against official vectors
        assert_eq!(out_buf[0..16], test_stream_0);
        assert_eq!(out_buf[16..32], test_stream_16);
        assert_eq!(out_buf[240..256], test_stream_240);
        assert_eq!(out_buf[256..272], test_stream_256);
    }
}

• out_buf は、キーストリームの先頭 272 バイトを格納するための配列です（比較用に先頭 4 つのサンプルを切り出すのにちょうど十分な長さです）。最初はすべてゼロで初期化されています。ループで初期化する代わりに、省略記法 [0x0; 272] を使用します。

  • 任意のバイトを 0x00 と XOR すると、そのバイト自身になります。そのため、ゼロバッファを暗号化するということは、単に実装のキーストリームを抽出していることになります。安全な暗号では、このキーストリームはランダムなバイト列と識別できないはずです。RC4 の場合、値は公式ベクトルと一致するはずです。

• 各 assert_eq! は、キーストリームのスライス（out_buf の一部）を、対応するテストベクトル（test_stream_*）と照合します。

  • ドキュメントの表に対応するオフセットで 16 バイトのチャンクを取得するために、スライス記法を使用している点に注目してください（たとえば、out_buf[240..256] は、272 のうち範囲 [240, 256) にあるバイトを意味します）。

crypto_tool/rc4 ディレクトリから cargo test を実行すると、両方のユニットテストが通ることを確認できるはずです。

running 2 tests
test tests::ietf_40_bit_key_first_4_vectors ... ok
test tests::sanity_check_static_api ... ok

要点

これで、最初の高保証ソフトウェアの一部を構築できました（RC4 アルゴリズム自体は除きます）。 あなたの RC4 ライブラリは次のようなものです。

• 完全にメモリ安全です。したがって #![forbid(unsafe_code)]
• スタンドアロンで、ほぼどこでも実行できます。したがって #![no_std]
• 公式 IETF テストベクトルを使用して、機能的に検証されています

このライブラリを使用してローカルファイルを暗号化するコマンドラインツールを書くという、楽しくて具体的な部分に進む前に、いったん立ち止まり、ここまでに説明してきた静的保証と動的保証のすべてのトピックの限界を理解する必要があります。

Rust は暗号ライブラリに適した選択肢でしょうか？

C および C++ の暗号ライブラリに関するある研究では、報告された脆弱性のうち、暗号自体に関連する欠陥が原因だったものは 27.2% にすぎない一方で、37.2% はメモリ安全性の問題でした³。

パフォーマンスとセキュリティはいずれも中核的な要件であるため、暗号は Rust の主要なユースケースです（しゃれのつもりです）。 この言語には活発な暗号エコシステムがあります。 pure-Rust の TLS ライブラリである rustls⁴ は、注目すべきプロジェクトの 1 つです。 2019 年には、ほぼすべてのカテゴリで OpenSSL を大きく上回りました⁵。

1. ASCII。Wikipedia（2022 年アクセス）。 ↩

2. ストリーム暗号 RC4 のテストベクトル。Internet Engineering Task Force（2011 年）。 ↩ ↩2

3. 独自暗号を作るべきではない理由：暗号ライブラリにおける脆弱性の実証的研究。Jenny Blessing、Michael A. Specter、Daniel J. Weitzner（2021 年）。本稿執筆時点では、この論文はまだ査読付きカンファレンスに採択されていないことに注意してください。 ↩

4. rustls。rustls Contributors（2022 年アクセス）。 ↩

5. Rust ベースの TLS ライブラリがほぼすべてのカテゴリで OpenSSL を上回った。Catalin Cimpanu（2019 年）。 ↩

制約と脅威モデリング

コンピューターセキュリティの厄介な点は、常に悪い知らせがあることです。 セキュリティの実務者として、私たちは制約を鋭く認識していなければなりません。 つまり、次のようなことです。

• 私たちは何に対して自信がないのか？

  • 潜在的な弱点を提示できないなら、自分たちの強みを過大評価している可能性が非常に高いです。それは危険な立場です。

• 型システムはどのような脅威に対してほとんど保証を提供しないのか？

  • すべての脅威ベクトルの構成が、私たちの攻撃対象領域を決定します。それが大きくなるほど、攻撃者に対して潜在的な侵入口をより多く提示することになります。最もリスクの高い領域は、多くの場合信頼境界にあります。

    • 脅威ベクトル: 攻撃者がアクセスする可能性のある経路。

    • 攻撃対象領域: 特定のシステムに存在する脅威ベクトルの集合。

    • 信頼境界: システム内の、信頼度の低いコンポーネントと信頼度の高いコンポーネントとの間のインターフェイス。

• 私たちの動的テストスイートでは、どの機能要件を検証できないのか？

  • ここには潜在的な設計上の欠陥が潜んでいます。システムがデプロイされた後にこうした見落としが発見されると、修正には高いコストがかかる可能性があります。

    • 設計上の欠陥: システムが要件を満たせなくなる原因となる、基本的な機能における欠陥（コード内のバグとは対照的なもの）。原則やパターンのレベルにあるもの。

このセクションでは、これまでに述べてきた静的および動的な保証に関する主張について、より広い文脈を提供します。 いわば現実確認です。 関連する幅広いトピックを手早く扱うため、少しあちこちに話が飛びます。

手動静的解析を永遠に！

セキュリティ脆弱性の潜在的な原因を3つ考えてみましょう。 いずれも、それぞれのバグを普遍的に適用できる形で定義することがほとんど不可能であるため、静的であれ動的であれ、効果的な自動解析を設計することが非常に困難です。

1. 不適切な入力検証: ユーザーが提供したデータが構文的にも意味的にも正しいことの検証に失敗する。

   • 例: ある Web ポータルがフォーム入力を検証するためにクライアント側（つまり回避可能な！）JavaScript だけを使用しており、その入力の1つがコマンド実行時にサーバー側シェルへ渡される。

2. 情報漏えい: 機微な¹情報や余計な情報を露出させる。

   • 例: ある認証サービスが内部のトラブルシューティング目的で詳細なログを記録しているが、そのログにはユーザーの平文パスワードが含まれている。本来その機微データはハッシュ化された形式でのみ保存されている。

3. 設定ミス: システムの設定時に誤った、または最適でないパラメーターを選ぶことで脆弱性を持ち込む。

   • 例: あるネットワークルーターがパスワード認証による SSH ログインを許可しており、出荷されるすべてのデバイスに同じデフォルトパスワードが使用されている。

現実には、最も洗練された型システムと最も包括的なテストスイートを組み合わせても、セキュリティを保証することはできません。

• 静的な制約: 実用的な型システムのセマンティクス内にエンコードされたプロパティによっては、ほとんどの脆弱性クラスを排除できません²。

• 動的な制約: 多くの複雑な状態はテストでカバーされておらず³、本番環境で再現することも困難です。

さらに、静的側面では、型同士の変換規則がプログラマーに誤解されることがあります。 特に複雑なクラス階層を持つ言語ではそうです。 キャストエラーが型の混同脆弱性を引き起こすことがあり、あるデータ型をエンコードしているメモリが別のデータ型として誤解釈され、型安全性の保証が破られます。

C++ では型の混同はどのように起こるのか？

C++ は静的型付けですが、依然として型安全ではない言語です。 極端な場合、その弱い型付けにより、プログラマーは論理的な関係をまったく持たない任意の型同士をキャストできます。

より一般的には、プログラマーは特定のオブジェクト階層内の型同士をキャストします。 これは文脈上は論理的に筋が通っていますが、微妙なエラーの可能性をもたらします。 静的チェックに合格したにもかかわらず、実行時に深刻な型の問題に遭遇する可能性があります。

• 1次の型の混同: たとえば、誰かが誤って親クラスのインスタンスをその子孫の1つへキャストし、その親が子孫のフィールドの一部を持っていないとします。存在しないフィールドの1つにアクセスすると、任意のデータをポインターとして扱ってしまう可能性があります！

さらに、メモリ破壊バグは一般に型安全性を損ないます。

• 2次の型の混同: プログラム自体にはキャストエラーが含まれていないかもしれませんが、別の場所にあるメモリ破壊バグによって、攻撃者がオブジェクトのメモリを書き込める可能性があります。具体的には、オブジェクト内部のメソッドディスパッチテーブル内のポインターを上書きすることです。同じ任意ポインターの問題に至る可能性があります。

このようなシナリオは、C++ で書かれたブラウザー、仮想マシン、データベースが一般的に悪用される仕組みです⁴。 対照的に、Rust は型安全（言語がすべての型変換に厳格で静的に強制される規則に従うことを強制する⁵）であり、メモリ安全（破壊がない）です。

私たちは依然として、熟練した人間による手動静的解析を、監査という形で必要としています。 つまり、知識のある人々がコードや設計文書を読み、攻撃者よりも先に脆弱性を見つけるということです。

本書では、優先度の高いバグクラスを網羅的に列挙することはしません。 この目的のためには、すでに高品質で自由に利用できるリソースがあります。 特に影響力の大きいものが、MITRE CWE Top 25 Most Dangerous Software Weaknesses⁶ と OWASP Top 10 Web Application Security Risks⁷ です。 前者は自らを次のように説明しています⁶。

2021 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses (CWE Top 25) は、過去2暦年に経験された最も一般的で影響の大きい問題を示すリストです。これらの弱点が危険なのは、しばしば見つけやすく、悪用しやすく、攻撃者がシステムを完全に乗っ取ったり、データを盗んだり、アプリケーションの動作を妨げたりすることを可能にするためです。

CWE Top 25⁶ によると、メモリ安全性の問題である「Out-of-bounds Write」は、2021年の第1位の弱点でした。 実際、このリストには safe Rust が完全に排除する問題がいくつか含まれています（例: Out-of-bounds Read、Use After Free、NULL Pointer Dereference）。 しかし、Rust を過大評価しすぎないようにしましょう。 列挙された弱点の大半は、Rust のコンパイラが推論できる領域の完全に外側にあります。 Rust ソフトウェアはトップ 25 を潰すうえで有利なスタートを切れますが、ソフトウェア保証には 必ず 手作業 のプロセスを含めなければなりません。 忘れないでください。ツールはスケールのための補助であり、知恵の代替ではありません。

例: 動的テストが RC4 バックドアを検出できない場合

2020 年 3 月は、世界的な Covid-19 パンデミックの始まりでした⁸。 それよりはるかに重要度は低いものの、この本との関連性は高い出来事として、同じ 3 月に、史上最大級のセキュリティ侵害の 1 つが発生しました。バックドア化された製品を介して拡散したマルウェアにより、30,000 を超える公的機関および民間組織が被害を受けたのです⁹。 その製品を提供していた企業である SolarWinds は、顧客に更新を出荷した時点で、悪意のあるコードがシステムに挿入されていたことに気づいていませんでした。

制限に関する議論を、例を使ってより具体的にしましょう。 Rust の静的チェックと私たちの動的テストベクターでは、RC4 実装が完全に安全であることを保証できないことを示します。

攻撃者がネットワーク上に足場を持ち、トラフィックを盗聴できると想像してください（例:「中間者」）。 攻撃者は、SolarWinds の手口のように私たちの組織のビルドシステムを侵害し、次のように RC4 ライブラリの実装にバックドアを仕込みました。

impl Rc4 {
    // ..new() の定義は省略..

    // ..apply_keystream() の定義は省略..

    /// Stateless, in-place en/decryption (keystream XORed with data).
    /// Use if entire plaintext/ciphertext is in-memory at once.
    pub fn apply_keystream_static(key: &[u8], data: &mut [u8]) {
        // Backdoor RC4 >:)
        let mut rc4 = if data.starts_with("ADMIN_TOKEN".as_bytes()) {
            Rc4::new(&[0xB, 0xA, 0xD, 0xC, 0x0, 0xD, 0xE])
        } else {
            Rc4::new(key)
        };

        rc4.apply_keystream(data);
    }

    // ..prga_next() の定義は省略..
}

apply_keystream_static に追加された悪意のあるロジックに注目してください。暗号化されるデータがテキスト ADMIN_TOKEN で始まる場合、この関数は指定された鍵を無視し、ハードコードされた鍵を使用します。

ハードコードされた鍵を事前に知っていれば、受動的な ネットワーク攻撃者は機密データをリアルタイムで復号でき、バックドア化されたライブラリを使用するあらゆるシステムの機密性を侵害できます。 能動的な ネットワーク攻撃者なら、そのトークンを傍受し、それを利用して新しい内部システムへ横展開する可能性があります。

さらに悪いことに、cargo test を実行するとすべてのテストが通ります。 IETF 文書¹⁰にあるテーブル/ベクターをすべて移植するために時間を投資していたとしても、動的テストスイートはこのバックドアを検出できないでしょう。

問題は、挿入された if の最初のブロックである悪意のある分岐が、データの先頭に ADMIN_TOKEN が現れた場合にのみ通ることです。 これは、私たちが当てる可能性が信じられないほど低い、たった 1 つの実行パスです。このような任意かつ不明瞭な条件をテストすべきだと知ることはできません。 そして、もしビルドシステムが侵害されていたなら、インプラントはおそらくテストビルド用のコードにはバックドアを仕込まないでしょう。

どれほど「あり得ない」のか？

RC4 ライブラリに、ランダム性を使用する補助テストを追加するとしましょう。 これは、ランダムなメッセージをランダムな鍵で暗号化した場合、後で 同じ鍵 で復号すると 元のメッセージ が得られることを検証します。

ADMIN_TOKEN は 11 文字の文字列です。 アルファベットを大文字と小文字の英字のみに制限した場合（数字/記号などはなし）、可能な 11 文字の文字列は 52^11 通りあります。 ランダムに ADMIN_TOKEN に当たる確率は、7 百京 分の 1 にすぎません。 実質的にゼロです。 そして、その探索空間は網羅的にテストするには大きすぎます。

これは、動的解析のアキレス腱を示しています。すなわち、単一の実行はプログラムの状態空間のごく小さなサンプルにすぎないということです。 関連するテストケースを書く先見性があれば、特定のバグの存在をテストすることはできますが、バグが存在しないことを証明することは決してできません。 バックドアについても同様です。

実用的なバックドアと回避

私たちのバックドアは静的に検出できる可能性があります。 特定の定数との比較に基づいて分岐し、指定されたパラメーターを上書きしています。 このパターンまたは類似したものに対する「シグネチャ」を生成することは可能です。ソースコードにアクセスできない場合でさえ可能です。

パッキング や 難読化（手作業でも自動でも、コードの解析を難しくする技術）によって補うことはできますが、それは裏目に出て、バックドア化されたプログラムをさらに疑わしく見せてしまう可能性があります。

この本は攻撃に焦点を当てているわけではありませんが、有効な防御者であるためには、回避戦術について一般的に認識しておくべきです。 暗号コードの場合、それは数学的な保証に悪影響を与えるような微妙な方法で アルゴリズム を破壊することを意味します¹¹。 上の例のように if 文を挿入することではありません（これは復号の場合すら扱っていません）。

実世界のシステムにおける状況的文脈

暗号化だけでは、完全性（データが変更または破損していないこと）や 真正性（データが信頼できる送信元から来たこと）は保証されません。 そして繰り返しますが、RC4 暗号はもはや安全とは見なされていません。

実世界で使用する場合、私たちはおそらく Associated Data 付き認証暗号（AEAD）¹²をサポートする暗号を求めるでしょう。 機密性を保護しながら、完全性と真正性の両方を検証するためです。 コミュニティの取り組みである RustCrypto 組織は、AEAD 互換の暗号（ストリーム暗号とブロック暗号の両方）を提供する、オープンソースかつ pure-Rust のクレート一覧¹³を保守しています。

RC4 がかつて SSL/TLS や WEP のような主要プロトコルの一部だったことを覚えていますか？ プロトコル設計においては、AEAD 暗号でさえ、すべてのセキュリティ要件を満たすには不十分です。 ネットワーク攻撃者が次のことを行うと想像してください。

1. 正当なブロードキャストパケットを待ち受ける。

2. 受信した各パケットのコピーを保存する。

3. 保存したパケットを、場合によっては後で、元の宛先へ再送信する。

その再送信は リプレイ攻撃 と呼ばれます。 攻撃者はパケットを復号、変更、または偽造することは一切ありません。AEAD はまったく侵害されません。 それでも、その結果は壊滅的になり得ます。

• 攻撃者が激しく再送信するとします。 宛先サーバーはパケット量に圧倒される可能性があります。 攻撃者のコピーの処理に追われていると、正当なユーザーへの応答期限を逃すかもしれません。つまり、サービス劣化、さらには サービス拒否（DoS） に見舞われることになります。

  • 防御例: クライアントごとのレート制限。

• 攻撃者が 1 回だけ再送信するとします。しかし、そのメッセージは入金を確認し、ユーザーの口座残高を増やすためのものでした。 攻撃者は単に自分のお金を倍にしただけかもしれません。

  • 防御例: 暗号化されたペイロード内の信頼できるタイムスタンプ、最後のコミットより新しいスタンプを持つトランザクションのみをコミットする（そして起こり得るラップアラウンドを処理する）。

暗号技術は、実世界のプロトコルやシステムのセキュリティにおける要因の 1 つにすぎません。 暗号化アルゴリズムが扱うのは、全体的な脅威モデルのうち 1 つの [中核的な] 部分だけです。

全体像: 脅威モデリング

このセクションでは、個々のコードブロックを超えたシステム設計の文脈である「全体像」の視点に何度か触れてきました。 高水準のセキュリティ設計レビューには、脅威モデリング¹⁴と呼ばれるプロセスが関わります。 一般に、ワークフローは次のようなものです。

1. システム内の資産（価値のあるデータまたはリソース）を特定する。

2. 各資産の攻撃対象領域を確認し、対応する脅威を列挙する。信頼できない入力の発生源を探すことは、よい出発点になり得る。

3. 脅威を順位付けする。優先順位を付ける一般的な方法の 1 つは、risk = likelihood * severity である。

4. 順位付けされた脅威に比例した管理策と緩和策を実装する。

5. 緩和策と管理策の有効性をテストする。

脅威モデリングは、アーキテクチャ設計時（コードが書かれる前）のように、プロダクトのライフサイクルの早い段階で行うと最も価値が高い。 問題を早期に発見して修正できればできるほど、修正は安く簡単になる（別名「シフトレフト」セキュリティ）。

脅威モデリングには複数の方法論が存在し、それらを扱う本も丸ごと存在する。 完全な方法論というよりは分類体系に近いが、STRIDE は人気があり、長く使われ続けているアプローチの 1 つである。 これは 2002 年に Microsoft に採用され、それ以降進化してきた。 この頭字語は次のように分解される¹⁵:

STRIDE は意図的に高レベルなものになっている。 幅広いプロダクト、システム、サービスに適用できることを目指している。 したがって、一般的に望ましい性質に焦点が当てられている。

より粒度の細かい脅威列挙フレームワークは、現実的な脅威モデルの作成に役立つ。 MITRE ATT&CK は現代的な例であり、次のように自己説明している¹⁶:

…現実世界の観測に基づく、敵対者の戦術と技法に関する世界中からアクセス可能なナレッジベース。ATT&CK ナレッジベースは、民間部門、政府、サイバーセキュリティ製品およびサービスのコミュニティにおいて、具体的な脅威モデルと方法論を開発するための基盤として使用されている。

コード解析の限られた側面はツールで補える場合がある一方で（例: Rust コンパイラによるメモリ安全性の証明）、脅威モデリングを自動化するには汎用人工知能が必要になる。 言い換えると、これは早い段階で前もって人の作業時間を見積もっておくべきタスクである。

まとめ

型システムは強力ではあるが、ほとんどのバグの種類をモデル化できない。 Rust は、現実世界のセキュリティ問題の大部分を解決するわけではない。 コードレビューと脅威モデリングを意味する手動解析は必須である。

コンパイラの型チェックと手動レビューの間に位置するものとして、半自動的な検証の形態がある。それが動的解析である。 これは通常、コードのビルド後、同僚にレビューを依頼する前に実行される単体テストという形を取る。

これらのテストは信頼性を高める助けになり、深刻な問題を検出できることもあるが、バグやバックドアが存在しないことを証明することはできない。 現実世界のプログラム（上記の単純なバックドアではない）では、これはテストスイートが 100% のコードカバレッジを達成している場合でも当てはまる。つまり、プログラムのすべての分岐が少なくとも 1 回は実行されている場合でもそうである。

なぜか。複雑なアプリケーションの状態空間は、実行された分岐だけの関数ではなく、データ片の値にも依存するからである（他の要因もある）。 そして 11 文字の順列の例で見たように、ごく小さなデータ片であっても、取り得るすべての値を網羅的にテストすることはできない。

より一般的に言えば、あるプログラムが悪意あるものかどうかを、信頼性高く判定できる自動ツールは決して存在しない。 あるいは、良性のプログラムがセキュアであるかどうかについても同じである。 その判定を行うことは、証明可能な形で不可能である（Rice の定理¹⁷）。

私たちがセキュアだと考えるシステムは、一般に時の試練に耐えてきたものである。 よく研究されたプロトコルや、徹底的に監査されたオープンソースプロジェクトのようなものだ。 しかし、新しい脆弱性は常に起こり得る。

覚えておいてほしい。絶対的なセキュリティは存在しない。 存在するのは保証のレベルだけである。

この文脈をすべて踏まえたうえで、RC4 ライブラリに戻り、それを有用なことに活用しよう。コマンドラインインターフェイスを介してローカルファイルを暗号化するのである。

サプライチェーン攻撃は深刻な問題である

ソフトウェアサプライチェーン攻撃は、前述の SolarWinds 事件のような標的型スパイ活動だけに限定されるものではない。 サードパーティ依存関係に依存するあらゆるソフトウェアプロジェクトは、バックドアを仕込まれた、またはその他の悪意あるパッケージを潜在的な脅威ベクトルとして警戒すべきである。 最近の 2 つの例を考えてみよう:

• 2022 年 4 月、人気のある npm パッケージ node-ipc の作者たちは、ロシアによるウクライナ侵攻に抗議するため、意図的にマルウェアを挿入した。この悪意あるコードは、IP ジオロケーションに基づいてロシアとベラルーシのホストを特定しようとし、位置が一致した場合にはディスク上のすべてのファイルの内容を置き換えようとした¹⁸（データ損失）。

• 2022 年 5 月、rustdecimal という名前の悪意ある Rust クレートが報告された。この名前は、良性の rust_decimal クレートのユーザーを標的にした「タイポスクワッティング攻撃」である。特定の関数が呼び出されると、この悪意あるクレートは CI 関連の環境変数が設定されている場合に実行可能ペイロードをダウンロードする。このペイロードのロジックは不明であり、問題が発見された時点ではダウンロード URL は無効になっていた¹⁹。

cargo-crev²⁰ や cargo-supply-chain²¹ のようなツールは、Rust プロジェクトの依存関係とその作者情報の評価を支援できる。 しかし、すべてのサプライチェーン攻撃を防げる技術的管理策は存在しない。 成熟した組織は、依存関係の審査と保守のためのプロセスやポリシーを採用することで、リスクを緩和できる場合がある。

1. Compositional Information Flow Monitoring for Reactive Programs. McKenna McCall, Abhishek Bichhawat, Limin Jia (2022). Information Flow Control (IFC) は、この論文の分野であり、機密情報の漏えいに対処する方法を探求している。形式的ではあるが、この研究が取り組む問題、すなわちタイトルにあるイベント駆動プログラムのサポートと異種コンポーネントの合成は、現実世界のシステムを代表するものである。情報漏えいは、最終的には体系的かつ原則に基づいた形で解決できる問題になるかもしれない。 ↩

2. 「型状態」パターン（一般的なものであり、Rust 固有ではない）は多少役に立つ場合がある。また、「セッション型」²² はメッセージパッシングプロトコルに特に有用である。 ↩

3. The Dirty Pipe Vulnerability. Max Kellerman (2022). ↩

4. HexType: Efficient Detection of Type Confusion Errors for C++. Yuseok Jeon, Priyam Biswas, Scott Carr, Byoungyoung Lee, and Mathias Payer (2017). ↩

5. Rust では、特定のプリミティブ型を as キーワードで変換できます。サイズの異なる整数がその一例です。ユーザー定義型間の変換には「トレイト」（共有される振る舞いのためのインターフェイスで、第3章で取り上げます）を使用します。具体的には From²³ と Into²⁴ です。これらは、型キャストのユースケースの大半を安全にカバーします。Rust プログラマーがビット列を任意に再解釈する必要が本当にある場合、unsafe 関数 std::mem::transmute²⁵ が最後の手段です。 ↩

6. 最も危険なソフトウェア脆弱性 CWE トップ25。The MITRE Corporation（2021）。 ↩ ↩2 ↩3

7. Webアプリケーションセキュリティリスク トップ10。OWASP（2021）。 ↩

8. 私たちのパンデミックの年—COVID-19タイムライン。Kathy Katella（2021）。 ↩

9. SolarWinds ハックの解説: 知っておくべきすべて。Saheed Oladimeji、Sean Michael Kerner（2021）。 ↩

10. ストリーム暗号 RC4 のテストベクトル。Internet Engineering Task Force（2011）。 ↩

11. Diffie-Hellman にバックドアを仕込む方法。David Wong（2016）。 ↩

12. 認証付き暗号。Wikipedia（2022年アクセス）。 ↩

13. RustCrypto: 関連データ付き認証付き暗号（AEAD）アルゴリズム。RustCrypto organization（2022年アクセス）。 ↩

14. 脅威モデリングチートシート。OWASP（2021）。 ↩

15. 脅威モデリング: 利用可能な12の手法。CMU SEI（2018）。 ↩

16. MITRE ATT&CK。MITRE（2022年アクセス）。 ↩

17. ライスの定理。Wikipedia（2022年アクセス）。 ↩

18. node-ipc に埋め込まれた悪意のあるコード。GitHub（2022）。 ↩

19. セキュリティアドバイザリ: 悪意のあるクレート rustdecimal。The Rust Team（2022）。 ↩

20. cargo-crev。cargo-crev Contributors（2022年アクセス）。 ↩

21. cargo-supply-chain。Rust Secure Code Working Group（2022年アクセス）。 ↩

22. セッション型の入門。Wen Kokke（2020）。 ↩

23. トレイト std::convert::From。The Rust Team（2022年アクセス）。 ↩

24. トレイト std::convert::Into。The Rust Team（2022年アクセス）。 ↩

25. 関数 std::mem::transmute。The Rust Team（2022年アクセス）。 ↩

DIY CLI 暗号化ツール

単体テストにより、私たちのライブラリが正しいことが示されました（少なくとも最初の、バックドアのないバージョンは）。 次はそれを使って、コマンドラインインターフェイス（CLI）の暗号化ユーティリティを構築します！

このツールは 2 つの引数、ファイル名と 16 進数の暗号化キーを受け取り、ディスク上のファイルを暗号化または復号します。

これらの要件は単純なので、Rust の標準ライブラリだけを使って CLI ツールを簡単に構築できます。

• std::env モジュール¹は、他の機能に加えて、OS に依存しない引数アクセス（正確にはパースではありません）を提供します。

• std::fs モジュール²は、OS に依存しないファイルシステム入出力（例: ファイルの読み書き）を提供します。

厳密に std だけを使って進めるのもよい方法です。 純粋主義者である場合や、手引きなしで問題に取り組みたい場合は、以下のプログラムを標準ライブラリだけを使うように適応してみてもよいでしょう。 ただしここでは、Rust のサードパーティライブラリエコシステムを試してみます。

実世界のコマンドラインアプリケーションでは、さまざまなサードパーティライブラリが使われています。 Rust の CLI エコシステムは、プラグアンドプレイ（構築とリンクが容易）な引数パース³、テキストの色付け⁴、統合テスト⁵、テキストベースのユーザーインターフェイス（TUI）⁶などを提供しています。 コミュニティが保守する膨大なライブラリ群により、CLI アプリの構築と保守は楽しいものになります。

それでは、人気のあるライブラリを試してみましょう。引数パースには clap クレート³を使います。 clap は Rust のマクロシステムを使って宣言的な引数パースロジックを可能にします。これはまもなく確認します。

成長する Rust エコシステムを活用する

Rust の強力な特徴の 1 つは、公式パッケージマネージャー兼ビルドシステムである cargo です。 私たちはすでに cargo を使って RC4 ライブラリをコンパイルし、テストしました。 しかし cargo の真価は、より広範な Rust エコシステムのライブラリをいかに簡単に活用できるかにあります。

現代の開発において、プログラミング言語の実用性は、コア言語機能と、誰かが開発・保守しているドメイン固有の抽象化がライブラリ（Rust では「クレート」と呼ばれます）の形で利用可能であることの両方によって決まります。

ソフトウェアエンジニアは、高品質なコードを素早く出荷する必要があります。 つまり、適切な場合には既存のコードを使ってプロダクトの立ち上げを加速するということです。 この記事の執筆時点で、Rust ライブラリの公式集中リポジトリである crates.io には 75,000 を超えるクレートがホストされています。

もちろん、すべてのクレートが十分に保守されているわけでも、本番品質であるわけでも、安全であるわけでもありません。 しかし、私たちには選択できる多くの選択肢があります。 そしてその数は、Rust エコシステムが成熟するにつれて増え続けるでしょう。

cargo は、clap の最新バージョンのダウンロードとビルドを処理してくれます。 私たちが行う必要があるのは、crypto_tool/rcli/Cargo.toml に 1 行追加することだけです。

[package]
name = "rcli"
version = "0.1.0"
edition = "2021"

# その他のキーとその定義については https://doc.rust-lang.org/cargo/reference/manifest.html を参照してください

[dependencies]
rc4 = { path = "../rc4" }
clap = { version = "^4", features = ["derive"] }

• features = ["derive"] は、clap ライブラリのオプション機能である derive マクロのサポートを有効にします。これにより、いくらかのボイラープレートを省けます。

• version = "^4" は、このツールが最新の clap バージョン >= 4.0.0 かつ < 5.0.0 を使うことを cargo に伝えます。Rust クレートはセマンティックバージョニング（semver、例: MAJOR.MINOR.PATCH）⁷に従うため、4.x.x バージョンでは API の安定性を期待できます。

rc4 依存関係とは異なり、clap にはローカルの path を指定していないことに注目してください。 cargo は、私たちが rcli プロジェクトを初めてビルドまたは実行するときに、crates.io からソースコードをダウンロードします。

サードパーティコードは信頼できるのか？

ほとんどのソフトウェアはサードパーティコードを活用しています。 しかし、取り込む外部コンポーネントはそれぞれ、バグや脆弱性をシステムに持ち込むリスクがあります。 このため、成熟した組織では依存関係やサプライヤーを審査するプロセスが整備されています。

文脈によっては、サードパーティ依存関係のソースを監査し、すべてのビルドで監査済みのバージョンだけを使う方が安全です。 内部リポジトリやビルドシステムの設定は、個々の企業やチームに固有です。

特定の問題クラスでは、サードパーティコードが実際にはリスクを低減することに注意してください。 暗号技術は典型的な例です。同じアルゴリズムを自分たちで実装するより、成熟したライブラリを取り込む方が良い可能性が高いでしょう。

手動の引数パースは C ほど Rust では危険ではありませんが、それでも clap を使うことでエラーの可能性を減らせます。

clap による引数のパース

clap の最も便利な機能の 1 つは、構造体のフィールドにアノテーションを付けられることです。 それぞれのアノテーションは、機械的には Rust マクロであり、引数の表示とパースを処理するコードを生成します。

• ユーザーが CLI ツールを呼び出すと、要求された設定/操作を含む単一の構造体（以下の Args）が得られます。

• 引数パースの複雑な詳細を気にする代わりに、「ビジネスロジック」、つまり要求されたタスクを実行するために構造体のフィールドを処理することに労力を集中できます。

これがどのように機能するか見てみましょう。 以下を crypto_tool/rcli/src/main.rs に追加してください。

use clap::Parser;

/// RC4 file en/decryption
#[derive(Parser, Debug)]
struct Args {
    /// Name of file to en/decrypt
    #[arg(short, long, required = true, value_name = "FILE_NAME")]
    file: String,

    /// En/Decryption key (hexadecimal bytes)
    #[arg(
        short,
        long,
        required = true,
        value_name = "HEX_BYTE",
        num_args = 5..=256,
    )]
    key: Vec<String>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

• Args は 2 つのフィールドを持つ struct です。

  • file は、暗号化/復号されるファイルのパス/名前を含む文字列です。

  • key は、スペース区切りの個々の文字列の動的配列です。各文字列はキーの 16 進数バイトになります。

• clap のフィールドアノテーション（#[something(...)] という形式のマクロ）のハイライト:

  • short - 短い引数名（例: file に対する -f）を生成します。

  • long - 長い引数名（例: file に対する --file）を生成します。

  • required = true - ツールを実行するには引数を提供しなければならないことを示します。

  • num_args = 5..=256 - RC4 の最小 5 バイト（40 ビット）および最大 256 バイト（2048 ビット）のキー長を強制します。

現在、2 行の main 関数は、ユーザー入力から収集した Args 構造体を出力するだけです。 フォーマット指定子 {:?} により、デフォルトフォーマッタを使用できます。Args は Debug トレイトを derive しているため、これをサポートしています。 トレイトについては次の章で説明します。

clap がサポートするアノテーションについて知るにはどうすればよいですか？

Rustには、組み込みのドキュメントシステムである rustdoc⁸ があります。 すべての公開クレートには生成されたドキュメントが提供されていますが、その完全性はプロジェクトによって異なります。 clap のドキュメントは https://docs.rs/clap で閲覧できます。

作業中のCLIツールを現状のまま実行するには、コマンド cargo run -- --help を使用できます。

RC4 file en/decryption

Usage: rcli --file <FILE_NAME> --key <HEX_BYTE> <HEX_BYTE> <HEX_BYTE> <HEX_BYTE> <HEX_BYTE>...

Options:
  -f, --file <FILE_NAME>
          Name of file to en/decrypt
  -k, --key <HEX_BYTE> <HEX_BYTE> <HEX_BYTE> <HEX_BYTE> <HEX_BYTE>...
          En/Decryption key (hexadecimal bytes)
  -h, --help
          Print help

-- 区切り記号は、入力の残りをCLIツールに渡すよう cargo に指示します。 この場合、渡しているのはフラグ --help だけです。 便利なことに、clap はこのフラグを私たちのために実装してくれています。 これはCLIツールで一般的な慣習だからです。 Args 構造体の各フィールドに対するコメント（/// で始まる行）が、ヘルプ出力の説明として使用されていることに注目してください。

しかし、--help は main 関数を実行しません。 ツールの通常の使用をシミュレートするために、cargo run -- --file test.txt --key 0x01 0x02 0x03 0x04 0x05 を試してみましょう。 最小の5バイトの鍵長を指定します。 main は次のように出力します。

Args { file: "test.txt", key: ["0x01", "0x02", "0x03", "0x04", "0x05"] }

引数の解析が動作するようになりました！

ファイルの暗号化/復号ロジックの実装

残っているのは、RC4ライブラリと新しいCLIフロントエンドをつなぐ「接着剤」だけです。 main を次のように更新しましょう（先頭に追加されたインポートに注目してください）。

use clap::Parser;
use rc4::Rc4;
use std::fs::File;
use std::io::prelude::{Read, Seek, Write};

// `Args` 構造体は省略、変更なし...

fn main() -> std::io::Result<()> {
    let args = Args::parse();
    let mut contents = Vec::new();

    // Convert key strings to byte array
    let key_bytes = args
        .key
        .iter()
        .map(|s| s.trim_start_matches("0x"))
        .map(|s| u8::from_str_radix(s, 16).expect("Invalid key hex byte!"))
        .collect::<Vec<u8>>();

    // Validation note:
    // `Args` enforces (5 <= key_bytes.len() && key_bytes.len() <= 256)

    // Open the file for both reading and writing
    let mut file = File::options().read(true).write(true).open(&args.file)?;

    // Read all file contents into memory
    file.read_to_end(&mut contents)?;

    // En/decrypt file contents in-memory
    Rc4::apply_keystream_static(&key_bytes, &mut contents);

    // Overwrite existing file with the result
    file.rewind()?; // "Seek" to start of file stream
    file.write_all(&contents)?;

    // Print success message
    println!("Processed {}", args.file);

    // Return success
    Ok(())
}

main に戻り値の型 std::io::Result<()>⁹ を追加しました。 Rustの Result 型については次の章で扱います。 ここで重要なのは、main の本体内にある、失敗する可能性のあるすべてのファイルI/O操作が ? 演算子で終わっている点です。 これは、操作が失敗した場合に関数を「短絡」させ、即座にエラーの Result を返すよう指示します。

たとえば、誰かがプログラムを実行し、存在しないファイルへのパスを指定したとします。

cargo run -- --file non_existant_file.txt --key 0x01 0x02 0x03 0x04 0x05

let mut file = File::open(args.file)?; の行は失敗し、次のエラーでプログラムを終了します。

Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

本番品質のツールでは、エラーを適切に処理したり、ログに記録したり、よりユーザーフレンドリーな出力でラップしたりできます。 エラーが発生しなかった場合は、成功を示すために Ok でラップした空の値（()、Rustのユニット型¹⁰）を返すだけです。

新しい main 関数には、説明する価値のある要素がさらにいくつかあります。

• バッファリングなし: ファイル全体を一度にメモリへ読み込み、バイトベクタ contents に格納します。大きなファイルのサポートは、バッファリングと呼ばれる技法を使えばより効率的にできます。これは、一度に小さなチャンクだけを読み込み/暗号化する方法です。この例では、代わりに単純さを目指しています。

• 任意のバイトプレフィックス: 鍵の変換ロジックでは、Rustの関数型スタイルのイテレータを使用しています。イテレータについては後で詳しく説明します。s.trim_start_matches("0x") により、ユーザーは各バイトにプレフィックス 0x を任意で追加できることに注意してください。つまり、--key 01 02 03 04 05 も有効で同等の入力になります。

• 入力検証: 自分で制御していない入力を解析するコードを書く場合、その入力は信頼できません。それは攻撃者に制御されている可能性があります。できるだけ早く、つまりプログラムやシステムの他のコンポーネントへ渡す前に検証してください。main では3段階の検証を使用しています。

  1. 有効な鍵長: 暗号化ライブラリが鍵長をチェックすると仮定する代わりに（私たちのRC4実装は実際にチェックします！）、Arg の key フィールドにアノテーション（例: num_args = 5..=256）を使用しました。エラーを確認するには、cargo run -- -f anything.txt -k 01 を試してください。

  2. 有効な16進数の鍵バイト: .expect("Invalid key hex byte!") は、鍵入力にbase-16バイトの無効な文字列表現（例: "0xfg"）を受け取った場合にプログラムが投げるエラーメッセージを決定します。

  3. 必要なファイル権限: std::fs はOSの機能を使用して、ユーザーが指定されたファイルを読み書きする権限を持っていることを確認します。権限がない場合、プログラムはエラーを投げます。これは先ほど見た Error: Os { code: 2, kind: NotFound... のケースと似ています。

検証に失敗した場合はどうすべきでしょうか？

それは運用コンテキストによって異なります。 できるだけ早い段階で、対処可能なエラーメッセージとともにCLIツールを終了することで、私たちは攻撃的プログラミングを実践しています。

• 私たちは、早期に失敗することが効果的な最初の防御線であると考えます。特定のエラーを決して許容しないことには利点があると考えています。

ファイル暗号化ロジックがネットワークサービスやプロトコルの一部であった場合、おそらく可用性、つまりシステムをオンラインで到達可能な状態に保つことを優先するでしょう。 防御的プログラミングのほうが適切です。

• エンドユーザーへの影響を最小限に抑えて障害から回復します。

それは、エラー（ステータスコードやプロトコルメッセージを通じて）を返し、すぐに新しいファイル暗号化リクエストの待ち受けに戻ることを意味するかもしれません。 終了する代わりにです。

ツールの使用

まず、このツールを他のコマンドラインユーティリティと同じように使えるようにインストールしましょう。 crypto_tool/rcli ディレクトリから、次を実行します。

cargo install --path .

これで rcli --help を実行できるはずです。 実際にコンパイルされたバイナリがどこにあるかを知りたい場合は、which rcli を実行してください。

ツールを試すために、秘密のメッセージを含むテキストファイルを作成します。

echo "This is a secret, don't tell anyone!" > secret.txt

cat を使って内容を確認できます。

$ cat secret.txt
This is a secret, don't tell anyone!

暗号化後は内容を表示できなくなります。 そのため、今のうちに xxd で見ておきましょう。

$ xxd -g 1 secret.txt
00000000: 54 68 69 73 20 69 73 20 61 20 73 65 63 72 65 74  This is a secret
00000010: 2c 20 64 6f 6e 27 74 20 74 65 6c 6c 20 61 6e 79  , don't tell any
00000020: 6f 6e 65 21 0a                                   one!.

xxd は3つの列を表示しました。

1. 左: ファイル内の16進数オフセット。
2. 中央: 16進バイトの列として表したファイルの生の内容。
3. 右: 生バイトのASCII¹¹デコード（私たちの秘密のメッセージ）。

-g 1 フラグは、その中央の列で各バイトを独立して表示します。

ファイルを暗号化しましょう。

rcli -f secret.txt -k 01 02 03 04 05

出力 Processed secret.txt が表示されるはずです。 もう一度 xxd -g 1 secret.txt を実行すると、次のようになります。

00000000: e6 51 0a 76 d0 54 b3 07 ad e3 21 2f 69 63 7d dc  .Q.v.T....!/ic}.
00000010: 45 a2 f0 20 76 db f6 f5 fd a1 6f c8 5a 6c 67 60  E.. v.....o.Zlg`
00000020: d9 e1 1d e3 87                                   .....

ファイルが暗号化されたため、バイト列が変わりました。 一番右の列は、もはや意味のあるASCII文字列には見えません。 もう一度 rcli を実行して、ファイルを復号し、元のメッセージを取り出せることを確認してください。

このツールは、ファイルを処理するときに「暗号化中」または「復号中」と表示できるでしょうか？

これまで見てきたように、暗号化と復号は実際には同じ操作です。 どちらの場合も、キーストリームとのXORを取っています。 データを隠したのか、それとも明らかにしたのかを示すユーザーフレンドリーなメッセージを表示するには、ファイルの開始時の状態を知る必要があります。

それは簡単な作業ではないことがわかります！ 任意のバイト列が暗号化されたファイルであるかどうかを判断するには、「セマンティックギャップ」を埋める必要があります。 それが、この章の課題の一部です。

主要チェックポイント

私たちは、移植性があり、メモリ安全なRC4ライブラリを作成し、公式テストベクターに照らして検証しました。 これは、ベアメタルの組み込みシステムでさえ、どこでも使用できます。

次に、clap クレートとRustの標準ライブラリを活用して、シンプルなRC4 CLIツールを構築しました。 このツールは、主要なOSならどれでもコンパイルできます。

すべてわずか171行のコードです。 すべてのテストを含め、暗号をゼロから実装しています。 そして、そのコードはネイティブにコンパイルされます。rcli は非常に高速です。 初めてのRustプログラムとしては悪くありません。

少し時間を取って、そのことを実感してください。 あなたはすでにかなり遠くまで来ています。 準備ができたら、この章を最後のトピック、運用上の保証で締めくくりましょう。

1. モジュール std::env. The Rust Team（2022年アクセス）。 ↩

2. モジュール std::fs. The Rust Team（2022年アクセス）。 ↩

3. クレート clap. clap-rs Project（2022年アクセス）。 ↩ ↩2

4. クレート owo-colors. jam1garner（2022年アクセス）。 ↩

5. クレート assert_cmd. Ed Page（2022年アクセス）。 ↩

6. クレート tui. Florian Dehau（2022年アクセス）。 ↩

7. セマンティック バージョニング 2.0.0. Tom Preston-Werner（2022年アクセス）。 ↩

8. rustdocとは？. ↩

9. 型定義 std::io::Result. The Rust Team（2022年アクセス）。 ↩

10. プリミティブ型 unit. The Rust Team（2022年アクセス）。 ↩

11. ASCII. Wikipedia（2022年アクセス）。 ↩

運用保証（2部構成の1）

ソフトウェア工学を土木工学と不利に比較することは、一種の決まり文句になっています。 よく投げかけられる挑発は、次のようなものです。

正しい橋、つまり私たちが渡るときに足元で崩れ落ちない橋を確実に建設できるのに、なぜ正しいデスクトップアプリケーション、つまりクラッシュせず、セキュリティホールも含まないアプリケーションを確実に書けないのでしょうか？

その含意は、土木技術者は厳格な基準を継続的に満たしている一方で、ソフトウェア技術者は同じ熟練度に到達できていない、というものです。 この論法は表面的には説得力があるように見えます。 私たちは皆、バグのあるソフトウェアを使ったことがありますが、橋が崩落するのを実際に見たことがある人はほとんどいません¹。

心配はいりません。私たちソフトウェア側の人間も、まだ面目を保てます。 この議論には少なくとも2つの欠陥があります。

• 悪意のある行為者を無視しています。 ソフトウェアは容赦ない攻撃にさらされており、その攻撃者は熟練した敵対者である可能性があります。デバイスの脱獄を試みるパワーユーザーであれ、マルウェアキャンペーンを収益化しようとするサイバー犯罪者であれ同じです。これらの敵対者に耐えることは、ネットワーク接続されたあらゆるシステムにとって基本的な設計要件です。一方で橋は、設計上、解体作業員や放火犯に耐性を持つ必要はありません。

• 誤った同等性に依存しています。 静的解析における「状態爆発」への言及を思い出してください。ソフトウェアには固有の組合せ的複雑性があります。さらに、ソフトウェアライブラリやフレームワークは、建設資材や建築技術よりもはるかに速いペースで変化します。橋には年単位で測られる期間にわたる保守が必要ですが、ソフトウェアシステムは2週間のスプリントで新機能を追加できます。この動的な複雑性は、セキュリティと信頼性のリスクをいっそう高めるだけです。

ここまで、この章ではソフトウェア保証を非常に頑丈な橋を建設することのように扱ってきました。 メモリ安全性と一般的な正しさについて論じた以外には、現実世界で悪意のある行為者と戦うために実際に何が必要なのか（上記の1つ目の欠陥に相当）には触れていません。 また、セキュリティが静止した標的であることも暗黙のうちに仮定してきました（上記の2つ目の欠陥に相当）。

より大きな視点

静的解析と動的テストは、純粋に予防的な手段です。 実際には、ほとんどのソフトウェアには、継続的な現場でのセキュリティサポートが必要です。 Rustの厳格なコンパイラを満足させること、手動レビューを受けること、網羅的な動的テストスイートに合格すること――これらはすべて、高保証製品を出荷するための前提条件にすぎません。

本番環境で稼働し始めたら、それらの製品はライフサイクル全体にわたってサポートされる必要があります。 運用保証が主題になります。 私たちは、絶えず変化する環境の中で悪意のある行為者に対応できなければなりません。

OPSECについて話しているのですか？

**運用セキュリティ（OPSEC）**は、もともとベトナム戦争時代の軍事用語でした²。 現代のIT用語では、機密情報が敵対者に漏れることを防ぐ手段を広く指します。 例としてパスワード管理を考えてみましょう。

• 同じ覚えやすいパスワードを複数のサイトで再利用しますか？

  • それは悪いOPSECです。本来は分離されているシステムに有効な認証情報を漏らしていることになります。

  • いずれか1つのサイトがパスワード保存のベストプラクティス（ソルト付きハッシュ³など）を使用しておらず侵害された場合、攻撃者はあなたのパスワードを再利用して、あなたの複数のアカウントを乗っ取る可能性があります（メールアドレス/ユーザー名を再利用していると仮定）。

• 各Webサイトで、一意で長く、ランダムに生成されたパスワードを使用しますか？

  • それは良いOPSECです。認証情報を漏らしていません。

  • 単一サイトの侵害は、他のアカウントのセキュリティには影響しません。

運用保証はより広い概念であり、機密データの機密性を超えた目標を持ちます。 OPSECは運用保証のサブセットと考えることができます。 前の例に戻りましょう。

• ランダムで一意なパスワードを使用することに加えて、常に多要素認証（MFA）を有効にし、ログをレビューしますか？

  • それは良い運用保証です。認証を強化し、定期的に過去の監査を実施し、機密性を保護しています。

  • 過去のデータに、奇妙な地理的位置のIPからのログイン試行が現れていることに気づいた場合、それは侵害の試みを示している可能性があります。

運用保証の分解

運用上の施策は、「構造化ロギング」⁴から「リモートアテステーション」⁵まで幅広く及びます。 ツールや技術の広がり全体を捉えるのは難しいため、ここでは3つの大きなカテゴリに分け、網羅的ではない例を示します。

システムライフサイクル

製品やサービスを最新の状態に保つためのプロセスとツールです。 比較的新しい「DevSecOps」⁶という包括的概念に含まれます。 例は次のとおりです。

• 継続的インテグレーション/継続的デプロイメント（CI/CD）におけるセキュリティスキャン
• 暗号化され、認証された無線経由のファームウェアアップデート
• バージョン管理され、フォールトトレラントな分散インフラストラクチャ（例：コンテナ化されたマイクロサービス）
• 資産インベントリ

ホストベースのサポート

個々のマシンを保護するための技術です。企業の従業員が使用するクライアントであれ、顧客向けサービスを実行するサーバーであれ対象になります。 例は次のとおりです。

• サンドボックス化
• 強化されたメモリアロケータ
• エンドポイント検知・対応（EDR）ツール
• アプリケーション固有のベストプラクティス設定

ネットワークベースのサポート

企業ネットワークをリモート攻撃から保護し、足掛かりの獲得に成功した攻撃者の移動を制限するための技術です。 例は次のとおりです。

• セキュアなAPIゲートウェイ
• Webアプリケーションファイアウォール（WAF）
• セキュリティ情報イベント管理（SIEM）システム
• 仮想プライベートネットワーク（VPN）インフラストラクチャとゼロトラストアーキテクチャ

運用保証は私たちのライブラリとどのように関係するのでしょうか？

この本の中心的な焦点は、堅牢なデータ構造ライブラリを書くことです。 初期の章で非常に広い範囲を扱うため、見失いやすい点です！ 私たちの旅の終盤では、運用保証におけるシステムライフサイクルの構成要素について実践的な経験を積みます。

私たちのライブラリを他のプログラミング言語、すなわち C と Python から利用可能にするバインディングを開発することで、高速で安全な Rust コンポーネントを既存のコードベースに統合するプロセスをシミュレートします。

おそらく、パフォーマンス上の理由から Rust で新機能を書く機会があるかもしれません。 あるいは、セキュリティ上重要でありながらメモリ安全ではないコンポーネントを、Rust の同等物で段階的に置き換えられるかもしれません。 いずれにせよ、Rust コードへのバインディングにより、チームは大規模システムを時間をかけて「堅牢化」（セキュリティ態勢を改善）できます。

要点

この本は「プロダクトセキュリティ」の観点に偏っています。 このセクションの目的は、より大きな全体像、すなわち「エンタープライズセキュリティ」の観点を少し体験してもらうことです。 ソフトウェアセキュリティに関する私たちの議論は、このより広い文脈なしには完全なものにはなりません。

次のセクションでは、システムライフサイクルカテゴリの一側面である、ネイティブクライアント向けのアプリケーションデプロイオプションを紹介します。 私たちは rcli プログラムを独立して動作するようにし、どのエンドユーザーに対しても確実に実行されるようにします。

1. 余談ですが、この本の著者のひとりは、崩落の 24 時間足らず前に、実際にピッツバーグの橋を歩いて渡っていました。国として比較的裕福であるにもかかわらず、老朽化し、十分に保守されていないインフラは、米国における深刻な問題です。 ↩

2. Operations security。Wikipedia（2022 年閲覧）。 ↩

3. Password Storage Cheat Sheet。OWASP Foundation（2022 年閲覧）。 ↩

4. エラー（何らかの「悪い」条件に達したシステムイベント）を構造化形式でログに記録すると、本番環境で発生した問題の診断に役立ちます。あるいは、セキュリティインシデントにより効果的に対応できます。 ↩

5. アテステーションとは、特定のマシンが、攻撃者によって挿入または改変されたソフトウェアではなく、事前承認済みの特定のソフトウェア一式を実行していることを証明するためのプロセスです。このトピックに関心がある場合は、「Trusted Platform Module」（TPM）が何を行い、Windows 11 でどのように使われているかを調べてみるとよいでしょう。 ↩

6. What is DevSecOps?。Redhat（2018 年）。 ↩

運用保証（2/2）

クライアント側の運用保証をほんの少し扱う時間です。 この章のコードをパッケージ化し、現場で「そのまま動く」ようにします。

私たちは、rcli ツールがほぼあらゆる Linux システム上で即座に動作するようにしたいと考えています。 単一の実行可能ファイルをコピーするだけでよいようにします。 セットアップも、OS 固有のパッケージマネージャーでライブラリを取り込むことも不要です。 すべてのユーザーに対して、毎回動作してほしいのです。

このセクションはレッドチームに関係しますか？

関係する可能性があります。 運用保証は、防御側と攻撃側が行う抽象的なゲームと考えることができます。 同様に、ネイティブ実行可能ファイルは異なる目的に役立ちます。

• 防御: 管理対象のさまざまなホスト（例: 「アセット」）向けの、高性能で信頼性の高いツール。

• 攻撃: 難読化に適したポータブルなプログラム¹。被害者が所有するホスト（例: 「ターゲット」）向け。

自立したバイナリのビルド

静的バイナリは、プログラムとその依存関係をまとめるための実績ある方法です。 これは、実行時に依存関係を見つけてロードするデフォルトである動的リンクの代替手段を提供します。 その機械的な違いを簡単に可視化してみましょう。

動的リンクでは、複数のプロセスが共有依存関係（例: 共有ライブラリ）の同じコピーを使用します。 共有関数は実行時に「解決」されます（呼び出し先のアドレスが決定されます）。 通常、それはプロセスが共有関数を最初に呼び出したときですが、プロセスが最初に「ロード」されたとき（例: プログラムが起動されたとき）である場合もあります²。 共有ライブラリがシステムコール、つまりハードウェアとやり取りするための OS カーネルへのリクエストを行うことは一般的ですが、必須ではありません。 ファイルの読み取りや書き込みにはシステムコールが必要です。

静的リンクは、システムライブラリによって通常提供されるサービスを含め、プログラムに必要なすべての実行可能コードを取り込み、すべてを 1 つのより大きなファイルに組み込みます。 その結果、スタンドアロンのアプリケーションになります。 実行時に何かを解決する必要はありません。 システムコールは必要に応じて直接行われます。

私たちは運用上のトレードオフを行っているのでしょうか？

はい。 防御側にとって、静的リンクはパッチ適用を複雑にします。 通常、OS のパッケージマネージャーはシステムライブラリを最新の状態に保ちます。 また、個々のプログラムは、関連するライブラリの単一の新しいコピーにリンクできます。

静的リンクでは、依存関係を最新の状態に保つために、個々のプログラムをそれぞれ置き換える必要があります。 特定のコンポーネントの集中管理されたコピーを管理する能力を失います。

複数のプロセスが同じ依存関係に依存している場合、静的にリンクされたプロセスはコードの重複を意味することもあり、その結果 RAM 使用量が増える可能性があります。

しかし、静的リンクは移植性に優れており、多くのプログラミング言語ではすぐにサポートされているわけではありません。 では、Rust ではどのように行うのか見てみましょう。

まず、rcli がデフォルトでは動的にリンクされることを確認します。 crypto_tool/rcli ディレクトリから、次を実行します。

cargo build --release
ldd ../target/release/rcli

ldd は、共有ライブラリ依存関係、つまり OS ディストリビューションが通常管理するものを表示する Linux コマンドです。 したがって、2 番目のコマンドは次のような内容を出力します。

linux-vdso.so.1 (0x00007ffc0196f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09369b9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0936c8e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0936996000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f093697b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0936975000)

各行は、rcli ツールが機能するためにファイルシステム上のどこかに存在すると想定している共有オブジェクト（.so ファイル）を表しています。

2 番目の項目（libc.so.6 で始まる行）は C 標準ライブラリです。 この章の導入で述べたように、私たちの rcli フロントエンドコードは libc の一部（例: 動的メモリ割り当て用）にリンクしています。 ただし、私たちの RC4 ライブラリはそうではありません（これは #![no_std] コンポーネントです）。

これらのライブラリの存在に依存しないようにするため、代わりに musl（小さな libc 代替³）を使用する静的バイナリをコンパイルできます。

rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl

• 最初のコマンドは新しいコンパイルターゲット⁴を追加します。これは一般に {Arch}-{Vendor}-{Sys}-{ABI} 形式の「ターゲットトリプル」で指定されます。

• 2 番目のコマンドは以前と同様に rcli をビルドしますが、今回はターゲットトリプル x86_64-unknown-linux-musl 向けにビルドします。

では、今度は musl ターゲットのバイナリに対して、もう一度 ldd を試してみましょう。

ldd ../target/x86_64-unknown-linux-musl/release/rcli

出力は次のようになるはずです。

statically linked

rcli 実行可能ファイルの 2 回目のビルドは、任意の x86_64 Linux システムで「そのまま動く」はずです！ 必要なのはバイナリをコピーすることだけです。

デバッグ情報の削除

この実行可能ファイルを配布したい場合、デバッグ情報（ソースコードとの対応付けを可能にするシンボルを含みますが、CLI のエンドユーザーが行う必要はないものです）を削除してサイズを減らすべきです。

ワークスペースの設定ファイル crypto_tool/Cargo.toml に次の release プロファイル設定を追加することで、この情報をバイナリから「削除」できます。

[profile.release]
strip = true

この設定は、フラグ --release（最適化を有効にします）付きでビルドされた任意のターゲットに適用されます。 スタンドアロンの Linux ユーティリティである strip⁵ を使うこともできましたが、ビルドパイプラインへよりきれいに統合するために cargo を活用しました。

musl の代替

musl を活用することは、やや小さめの静的バイナリをビルドする一般的な方法ですが、musl には癖があります。 特にパフォーマンスに関してです。

代わりに、プラットフォームの標準Cランタイム（“CRT”）を静的リンクするには⁶:

RUSTFLAGS='-C target-feature=+crt-static' cargo build --release --target x86_64-unknown-linux-gnu

警告: musl を使う方法とは異なり、生成されるバイナリは依然として vdso のようなものに対して動的にリンクされる場合があります⁷。ldd を使って検証できます。

要点

完全に自立したツールをビルドする方法を実演しました。 私たちのバイナリは、特定のOSおよびISAのほぼあらゆるクライアント上でネイティブに実行されます⁸。

これでソフトウェア保証の概観は終わりです！ 次の章では、Rustそのものを掘り下げます。

1. hellscape。meme（2021年アーカイブ）。 ↩

2. ld.so。Linuxマニュアル（2022年アクセス）。Linuxでは、この挙動は LD_BIND_NOW 環境変数を空でない文字列に設定することで有効化できます。共有関数の解決をロード時に行う利点は、実行時パフォーマンスがわずかに予測しやすくなることです。プロセスのデバッグにも役立つ場合があります。 ↩

3. musl libc。Rich Felkerおよびコントリビューター（2022年アクセス）。 ↩

4. Platform Support。The Rust Team（2022年アクセス）。 ↩

5. strip。Linuxマニュアル（2022年アクセス）。 ↩

6. RFC 1721。The Rust RFC Book（2022年アクセス）。 ↩

7. vdso。Linuxマニュアル（2022年アクセス）。 ↩

8. 命令セットアーキテクチャ（Instruction Set Architecture）、例: x86_64。 ↩

ハンズオン課題: CLI暗号化ツールの拡張

この章で作成した rcli ツールはかなり基本的なものです。 これは意図的なもので、Rustの機能とツール群を簡単に紹介するためのものでした。

最初の課題の目標は、このCLI暗号化ツールを拡張することです。 読者の中には、Rust言語をより体系的な形で紹介する次の章を終えてから、この課題に取り組みたいと思う人もいるかもしれません。 一方で、今すぐコードを書きたくて、進めながらRustをさらに学ぶことをいとわない人もいるでしょう。

以下に、このツールを拡張するための提案をいくつか示します。 1つ以上を選んで構いません。 もちろん、独自のアイデアを実装しても構いません！

コア暗号技術

• 暗号化アルゴリズムを、私たちのRC4実装から、自分で選んだ現代的なAEAD暗号に切り替えてください。選択するには、さまざまな暗号の長所と短所について調査する必要があります。

  • RustCrypto organizationはいくつかのAEADアルゴリズム実装を保守しています¹が、他にも適した成熟したライブラリが見つかるかもしれません。

  • ハードウェア製品の脅威モデルには、デバイスに24時間365日物理的にアクセスできる攻撃者が含まれる場合があります。タイミングおよび電力サイドチャネル耐性について保証を提供するアルゴリズムと実装を見つけられますか？²

CLI UX

• ユーザーが既存のファイルを上書きする代わりに、新しい暗号化ファイルを作成できる機能を追加してください。ユーザーが既存のファイルを上書きすることを選んだ場合は、色分けされた警告を表示してください（ターミナル出力に色を付けるためのサードパーティライブラリを選ぶ必要があります）。

• ディレクトリ内のすべてのファイルを再帰的に暗号化する機能を追加してください（これをテストするときは十分に注意してください。ダミーファイルを含む新しいディレクトリを作成したくなるはずです！）。

• コンソールに Processed {file_name} と出力する代わりに、Encrypted {file_name} または Decrypted {file_name} のいずれかを出力するようにツールを更新してください（ヒント: 暗号化されたバイトストリームを識別するためにテストできるヒューリスティックはありますか？）。

• バッファリングを使って、一度にメモリへ読み込むには大きすぎるファイルの暗号化をサポートしてください。

CLI統合テスト

• CLIバイナリを実行し、コマンドライン引数と暗号化または復号する一時ファイルの両方を提供する統合テストを追加してください。テストハーネスをセットアップするには、1つ以上のサードパーティライブラリを使いたくなるでしょう。

• 無効な入力が適切に処理されることを確認するネガティブテストは、セキュリティテストの重要な一部です。統合ハーネスがそのようなケースを明示的にチェックするようにしてください。

1. RustCrypto: Authenticated Encryption with Associated Data (AEAD) Algorithms。RustCrypto organization（2022年アクセス）。 ↩

2. サイドチャネル攻撃は、物理システムによって漏えいした情報（タイミング、消費電力、電磁放射、音響放射など）を利用して、セキュリティを侵害します。暗号技術の文脈では、これはしばしば間接的な手段で秘密鍵素材を抽出することを意味します（ソフトウェアのバグは悪用されません！）。一部の暗号アルゴリズムは、この脅威モデルを念頭に置いて設計されています。それらの操作は、外部から観測可能なばらつきを減らすよう慎重に構成されており、サイドチャネル攻撃を著しく困難にするか、完全に非現実的なものにします。 ↩

Rustゼロクラッシュ講座

注: 本章の内容は改訂される可能性があります。

前章では、ソフトウェアセキュリティの概念を紹介するために、RustライブラリとCLIツールを一通り見てきました。 本章ではRust言語そのものに焦点を当て、その構文、機能、慣習を概観します。

ただし、Rustのすべてを扱うわけではありません。 Rustは大きな言語です。 CよりもC++にはるかに近いものです。 私たちが気に入っている包括的なRust本であるProgramming Rust¹は、700ページを超える大著で、言語機能を容赦なく列挙しています。 これは驚異的な本であり、本書にも大きな着想を与えてくれました。 しかし、それを読み通すには、コストコのミニ樽入りホールビーンコーヒーを何樽も消費するような持久力が必要です。

課題の一部は、Rustが提供する機能の幅広さそのものにあります。 比較的新しい言語であるRustには、後知恵の利点があります。つまり、先行する言語の成功した側面を自由に選び取れるのです。

これには、OCamlの代数的データ型、C++の単相化、Schemeの衛生的マクロなどが含まれます²。 Rustチームは一貫した設計を目指していますが³、この言語はいくつもの影響をうまく取り扱っています。

幸いなことに、Rustで生産的に作業するために、Rustを網羅的に理解する必要はありません。 このセクションでは、重要な概念を先取りして紹介します。Rustのスニペットを読み書きし始めるのに十分な内容です。 本書の残りの部分では、組み込みに適した高保証ライブラリを構築しながら、それらの概念を定着させます。

その基礎があれば、実世界のRustプログラムを自分で書く準備が整います。 また、プロジェクトの必要に応じて、追加の言語機能（スマートポインタ、チャネル、async、マクロなど）の学習にも取り組めるようになります。

Rustのツアーは、やや短めの6つのパートに分けます。

1. 低レベルのデータ表現 - プリミティブ、タプル、配列、参照、スライス。

2. 高レベルのデータ表現 - 構造体、列挙型、ジェネリクス、トレイト。

3. 制御フロー - 条件文、ループ、パターンマッチング。

4. 所有権の原則 - Rustの最も斬新な機能の中核原則を理解する。

5. 実践における所有権 - 日々所有権を扱うための概念。

6. エラー処理 - 失敗の伝播、および/または可用性の維持。

実地で検証済みの保証ガイドラインを重視する

本書は、堅牢で信頼性が高く、安全なシステムを構築するための入門書です。 したがって、本章タイトルのゼロクラッシュというしゃれがあります。

実践可能な保証技法を重視するために、Rustのツアーを、確立された業界標準の文脈で位置付けます。 最も容赦のない本番環境で検証されてきた知見に基づくものです。

Motor Industry Software Reliability Association (MISRA) C⁴ガイドラインは、その頭字語が示すとおり、もともとは自動車業界向けに作成されたCソフトウェア開発ルールの集合です。

スタイルガイドとは異なり、MISRA Cは安全性が重要なシステムの開発者向けにベストプラクティスを概説しています。 これは信頼性、セキュリティ、保守性を最大化することを意図しています⁵。 バグが生命を危険にさらす可能性のあるシステムのためのものです。

現在、これらのガイドラインは、航空宇宙、防衛、通信、医療機器の各業界で広く使用されています（DO-178C⁶やISO-26262⁷のような業界固有のフレームワークに加えて）。 最新バージョン⁸では、次のように紹介されています。

MISRA Cガイドラインは、間違いを犯す機会が取り除かれる、または減らされるC言語のサブセットを定義する。 安全関連ソフトウェアの開発に関する多くの標準では、言語サブセットの使用が要求または推奨されており、これはセキュリティ、高い完全性、または高い信頼性の要件を持つ任意のアプリケーションの開発にも使用できる。

MISRA Cは何十年にもわたって検証され、洗練されてきました。 規制上の認証の外であっても、これらは高保証システムを構築するための実践的なガイドラインです。

Rustの中核設計は、安全で信頼性の高いソフトウェアの構築に直接適用できます。 unsafeキーワードを使用しないため、本書はRust言語の安全なサブセットを紹介していると言えるでしょう。

本書の目的における「安全なサブセット」

Rustプログラミング言語の「安全なサブセット」を真に構成するものは、現在の標準化および研究活動の対象です。 本書では、安全なサブセットを形式的に定義しようとはしません。

代わりに、コアプロジェクトでは、実務のエンジニアが「安全なサブセット」と見なせるものに自分たちを制限するために、クレート全体に適用される2つのマクロを使用します。

• #![forbid(unsafe_code)]: unsafeキーワードの使用はコンパイル時エラーになります。これは、Rustの静的保証を最大化するのに役立ちます。

• #![no_std]: 標準ライブラリの機能（unsafeコードを含みます）は使用しません。より厳密には、すべての動的メモリ使用をオプトアウトします。外部アロケータに依存しないことには、一定の堅牢性上の利点があります。

コアプロジェクトはオープンソースライブラリ⁹に基づいているため、これらの制約内で作業することが、自明でないコードベースに対しても実行可能であることがわかっています。

さて、Rustは新しい言語であるため、安全性が重要な環境での使用についてはまだ広く認証されていません。ただし、これは業界での取り組み¹⁰および研究¹¹が進められている分野です。 自動車（ISO 26262）および産業（IEC 61508）用途向けの認定済みRustコンパイラはありますが、MISRA Cガイドラインに対応するRust版はありません。 まだありません。

多くのMISRA CルールはC言語に固有です。 残りの一部を2つのカテゴリに分け、区別するために次のラベルを使用します。

• Rustにより自動化（AR）: 一貫して従うことが容易なルール、または慣用的なRustで自然に表現できるルール。どのRustプログラムでも、コンパイルできるなら、このカテゴリに従っている可能性が高いです。

• Rustでも信頼性高く適用可能（RR）: 正確性と堅牢性を優先するプログラムの設計および実装に一般的に適用できるルール。Rustでも容易に適用できますが、自動ではありません。プログラマ側の意識的な努力が必要です。

Rust言語の安全なサブセットを紹介する中で、該当するMISRA C⁸ルールを時折取り上げます。 本章と本書全体の両方で、上記のラベルのいずれかを前に付けます。

予告として、これから書くコアライブラリで準拠する3つのMISRA Cルールを示します（ただし、構築または使用する開発ツールについては、安全性が重要ではないため対象外です）。

[RR, 指令 4.1] 実行時障害を最小限に抑える⁸

[RR, 指令 4.12] 動的メモリ割り当てを使用してはならない⁸

[RR, 規則 17.2] 関数は自身を再帰的に（直接または間接に）呼び出すことはできない⁸

ここでは根拠を省いていることに注意してください。 上記の3つの規則が制約的に見える場合、それらは説得力を持ちます。 幸い、Rust ではこの種の高保証基準を満たすことが実現可能であり、かつ人間工学的です。

MISRA C に対する独自の見方

著作権を尊重するため慎重を期し、各 MISRA 規則の「見出し」については大まかな言い換えのみを提供します。その正確な文言、完全な説明、根拠、例外、カテゴリなどは提供しません。 これは、MISRA 規則を列挙している学術出版物¹²が採用しているのと同じアプローチです。

いくつかの場合、私たちの言い換えでは MISRA C Guidelines には存在しない Rust 固有の用語を導入します。 MISRA 規則を Rust に対応付ける先行研究¹³とは異なり、私たちは網羅性を目指しているわけではありません。 保証の概念を学ぶ目的で規則を抽出しています。

本章で言及する MISRA の規則と指令は、次のように分類できます。

大まかに言えば、指令とは、決定的かつ普遍的な方法で記述するのが難しい MISRA 規則です。 指令は、複雑なシステムではチェックや検証がより困難になる傾向があります。 一方で、規則は完全に捉えることが可能です。 多くの場合、静的解析ツール（Rust コンパイラなど）によって正確に検証できます。

繰り返しますが、私たちの MISRA 規則と指令のサンプルは網羅的ではないことに注意してください。 あなたがプロのセーフティまたはセキュリティエンジニアであれば、MISRA C 2012 Guidelines の完全版を MISRA から直接購入することをお勧めします。 広く採用されているベストプラクティスを理解することは、プロジェクトが使用する具体的なツールチェーンに関係なく価値があります。

Rust におけるソフトウェアエンジニアリング

高保証であるかどうかにかかわらず、現代の開発は言語構文や言語機能以上のものです。 それにはツール、プロセス、そして最も重要なものとして人が関わります。外部の顧客と内部のチームです。

効果的なプロセスを実装し、ステークホルダーのニーズに応える方法を学ぶ最良の方法は、プロとしての経験です。 本書ではツールに焦点を当てます。

前章で clap を使用したことで、サードパーティライブラリをビルドに統合する感覚をすでに得ました。 また、Rust の組み込みのファーストパーティ単体テストフレームワークを活用して、私たちの RC4 実装を公式テストベクターに照らして検証しました。 とはいえ、日々の開発タスクを支援するために cargo ができることについては、まだ表面をかすめただけです。 The Cargo Book¹⁴ では、より完全な概要が提供されています。

本章では、Rust のツールエコシステムの構成要素を、ファーストパーティとサードパーティの両方からさらにいくつか取り上げます。 また、本番システムで安定性がどのように実現されるのかを理解するために、Rust のリリースサイクルについても説明します。 より一般的には、成功するソフトウェアプロジェクトの重要な柱であるコード構成について取り上げます。

簡単な前提知識: スタック、ヒープ、値

本章では、「スタック」と「ヒープ」という2つの技術用語をときどき使用します。 この文脈では、これらの用語は2種類の異なるメモリ位置を指します。 同じ名前のデータ構造のことではありません（残念な専門用語の過負荷です）。

次章ではメモリについて詳しく説明します。 今のところは、次のように考えてください。

• スタックメモリは、すぐに利用可能な短期的な（関数呼び出しの期間だけ生存する）ストレージです。ただし、固定サイズの変数しか格納できません。

  • スタックの仕組みは CPU ハードウェアと密接に関係しています。実際、多くのプロセッサには「スタックポインター」と呼ばれる特定のレジスタがあります。

  • スタックメモリはスタックデータ構造のように動作します。メモリの「フレーム」は*後入れ先出し（LIFO）*です。

  • 整数と配列はデフォルトでスタック上に格納されます。

• ヒープメモリは、明示的に要求し、後でクリーンアップしなければならない長期的な（解放されるまで生存する）ストレージです。ただし、サイズが実行時に決定される変数を格納できます。

  • ヒープの仕組みはソフトウェアによって処理されますが、DRAM ハードウェアに対応します。通常は OS¹⁵ と連携して動作するメモリ割り当てライブラリが、RAM のチャンクを管理する複雑なロジックを実装します。

  • ベクターと非リテラル文字列は通常、ヒープ上に格納されます。

スタックとヒープの区別はコンピューターアーキテクチャ上の関心事であり、システムプログラミング言語の構文に現れる必要があります。 「ハードウェアに近い」プログラミングには、ハードウェアとソフトウェアのインターフェイスを反映したメンタルモデルが必要です。

「値」も本章で使用する用語です。 これはあらゆる種類のプログラミング言語にまたがる概念です。

• 値とは、型付けされたデータの、メモリ位置に依存しない具体的なインスタンスです。

たとえば、let string_literal = "Hello, World!"; において、string_literal は値 "Hello, World!" が代入された変数（ラベル）です。この値には2つの部分があります。

1. 型（ここでは T: &'static str。このシグネチャの読み方は後で分解して説明します）

2. 具体的なビットパターン（特定の UTF-8 文字列 "Hello, World!" をエンコードする何か）。

それでは、ゼロクラッシュコースを始めましょう。

学習成果

• 高保証ソフトウェアを書くための主要なガイドラインを学ぶ。
• 「未定義動作」とその影響を理解する。
• Rust 言語の中核機能を学び、Rust のスニペットを読み書きすることに慣れる。
• 日々のソフトウェアエンジニアリング作業を容易にするために必須の Rust ツールを学ぶ。

1. [個人的なお気に入り] Programming Rust: Fast, Safe Systems Development. Jim Blandy, Jason Orendorff, Leonora Tindall (2021). ↩

2. The Rust Reference: Influences. The Rust Team (2021). ↩

3. Josh Triplett on Building the Build System of his Dreams. Sean Chen (2022). ↩

4. MISRA C. MISRA (Accessed 2022). ↩

5. Assessing the Value of Coding Standards: An Empirical Study. Cathal Boogerd, Leon Moonen (2008). MISRA C 2004 標準を評価したこの論文は、72 個の MISRA 規則のうち欠陥検出に有意に効果的だったのは 12 個だけであり、特定の規則に従うことが、直感に反して、実際には欠陥率を増加させる可能性があると主張しています。これらの結論には議論の余地があり、MISRA C や同様のコーディング標準は、いくつかの業界で引き続きベストプラクティスとなっています。同じ著者による後続研究を除けば、同様の結論に至った他の研究は見つかりませんでした。しかし、完全性のためには、そのような主張にも言及する価値があります。読者には健全な懐疑心を保つことをお勧めします。少なくとも、コーディング標準の影響と適用にはニュアンスがあることには同意できます。 ↩

6. DO-178C. Wikipedia (Accessed 2022). ↩

7. ISO 26262. Wikipedia（2022年参照）。 ↩

8. MISRA C: 2012 Guidelines for the use of the C language in critical systems (3rd edition). MISRA（2019）。 ↩ ↩2 ↩3 ↩4 ↩5

9. scapegoat. Tiemoko Ballo（2022年参照）。 ↩

10. Ferrocene. Ferrous Systems（2021）。 ↩

11. Towards Rust for Critical Systems. Andre Pinho, Luis Couto, Jose Oliveira（2019）。 ↩

12. The MISRA C Coding Standard and its Role in the Development and Analysis of Safety- and Security-Critical Embedded Software. Roberto Bagnara, Abramo Bagnara, and Patricia Hill（2018）。 ↩

13. MISRA-Rust. Shea Newton（2022年参照）。 ↩

14. The Cargo Book. The Cargo Team（2022年参照）。 ↩

15. ユーザー空間の「メモリアロケータ」は、必要に応じてヒープ容量を増やすために、OS に対して「システムコール」を発行できます。プログラムがヒープメモリを使用する場合、このランタイムサポートライブラリにリンクしなければなりません。これは非常に一般的であり、ほとんどのプログラムはこのように動作します。 ↩

未定義動作について

MISRA Cの主要な目標の1つは、コードベースに存在する「未定義動作」（UB）¹の量を減らすことです。 第1章でUBについて少し触れましたが、これは不可欠な概念です。 UBを排除することは、高保証ソフトウェアにとって必要ですが、それだけでは十分ではありません。 そこで、Rustの構文に入る前に、このトピックに取り組みましょう。

ISO C標準²は、動作を次のように定義しています。

外部から見た様子または作用。

したがって、**未定義動作（UB）**は次のように定義されています²。

移植性のない、または誤ったプログラム構成要素、あるいは誤ったデータを使用した場合の動作であり、この国際標準がいかなる要件も課さないもの。

言い換えると、開発者がうっかりUBを引き起こした場合、プログラムは文字どおり何でもできます。 クラッシュしたり、不正な結果を生成したり、一見無関係な一連の操作を実行したりする可能性さえあります³。

ここで「未定義の操作は文字どおり何でもできます」とは言っておらず、「プログラムは」と言っていることに注意してください。 UBについて理解しておくべき重要な事実が1つあります。

• 未定義動作が引き起こされると、その悪影響は多くの場合、局所化できません。システム全体のセキュリティや信頼性を損なう可能性があります。

UBは、バグや脆弱性の望ましくない原因です。 しかし、複雑な歴史的理由がさまざまにあるため、UBはCとC++の両方の標準に深く組み込まれています。 どちらかの言語からUBのごく一部を取り除くだけでも、利用可能なコンパイラの大部分、または既存のコードをコンパイルする能力が壊れてしまいます。 そのため、実現する可能性は低いでしょう。

私たちにできる最善のことは、それを避けるために入念に努力することです。 つまり、C系のコードベースを徹底的に監査し、綿密にテストすること、そして可能な場合にはRustを導入することを意味します。

CでUBを導入するのはどれほど簡単か？

CおよびC++プログラムは、メモリ安全な言語と比べて、デバッグが難しく悪用されやすいです。なぜなら、UBの導入は些細であり、かつ一般的だからです。

研究者たちは、LinuxカーネルやPostgreSQLのような広く使われているプロジェクトでUBの事例を発見しています⁴。 第1章でその深刻度と蔓延状況を説明したメモリ破壊バグは、UBの結果の1つにすぎません。

UBがどのようなものか、具体的に感じてみましょう。 以下のCプログラムを考えてください。これは何を返すでしょうか？

#include <stdio.h>

int undef_func() {
    int uninit_var; // 一度も代入されない！
    if (uninit_var > 0) {
        return 1;
    } else {
        return 0;
    }
}

int main() {
    printf("%d\n", undef_func());
}

これはひっかけ問題でした。 答えは1または0であり、その時点でたまたまメモリに入っていた内容によって決まります。 単にif文が未初期化の値を読み取り、その結果に基づいて分岐したからです。 C標準（6.7.8、段落10²）は次のように述べています。

自動記憶域期間を持つオブジェクトが明示的に初期化されない場合、その値は不定である。

C標準の文脈では、「不定」とは、変数が次のいずれかであり得ることを意味します。

• その型の任意の正当な値を取る（例：「未規定値」）。

• その型のいかなるインスタンスも表さない値を取る（例：「トラップ表現」）。UBが発生します。

どちらの場合も、プログラムの信頼性にとって良い兆候ではありません。 この単純な関数は、標準のこの部分を明示的に対象とするMISRA Cのルールに違反しています。

[AR, Rule 9.1] オブジェクトの値は、書き込まれていない場合には読み取るべきではない⁵

デフォルトでは、人気のあるオープンソースのCコンパイラであるgccは、この重大なエラーについて警告しません。 以下の警告を得るには-Wallフラグを渡すことを覚えておく必要があり、それでもプログラムはビルドされ実行されます。

undef.c: In function ‘undef_func’:
undef.c:5:8: warning: ‘uninit_var’ is used uninitialized in this function [-Wuninitialized]
    5 |     if (uninit_var > 0) {
      |        ^

残念ながら、特別なコンパイラフラグを覚えておくことは一般的な解決策ではありません。 Cには起こり得る未定義動作が何百もあり、その大多数はコンパイラ警告では検出できません。 したがって、こうした「不正動作」は、コードベースが複雑になるにつれて急速に入り込んでいきます。

この問題の実例は何でしょうか？セキュリティの文脈では？

CVE-2022-0847、別名「Dirty Pipe」は、5.8以降のLinuxカーネルバージョンに影響する、非常に悪用しやすい脆弱性でした（安定版リリース5.16.11、5.15.25、5.10.102でパッチ適用済み⁶）。 コードのリファクタリングによって構造体のフィールドが未初期化になり、そのUBの事例はコンパイラ警告やテストでは検出されませんでした。

未初期化フィールドは、カーネル空間のpipe_bufferデータ構造のflagsメンバーでした。 これはカーネルが「パイプ」を設定するために使用されます。パイプはプロセス間通信（IPC）機構です。

通常の非特権操作を一連実行することで、攻撃者は、後でページキャッシュの書き込み権限のフラグとして読み取られる（正しくリセットまたは初期化されるのではなく）メモリ上の値を、確実に制御できました⁶。

この不正に得た権限を悪用してファイルにパイプすることで、攻撃者は読み取り専用であるべきシステムファイル内の小さな内容の塊を上書きできます。 これにより、とりわけ、rootパスワードを変更してローカル権限を昇格させ、その後リモートアクセスに使用されるSSH鍵データを上書きすることが可能になります。

実質的に、攻撃者はユーザーに非特権プログラムを実行させるだけで、脆弱なシステムの「完全な制御」を取得できます。すべては1つの未初期化フィールドが原因です！ 攻撃者に少しでも隙を与えれば、大きな被害につながる可能性があります。

それをRustで試してみましょう

Rustでも、unsafeキーワード⁷を使用すれば未定義動作は依然として可能ですが、Rustの安全なサブセットではほぼ排除されています。 これは、Rust言語が正しく信頼性の高いソフトウェアを書くのに非常に適している大きな理由の1つです。 Rustはデフォルトで、UBをほぼ完全に取り除きます。

「ほぼ排除」と「ほぼ完全に」という但し書きはなぜ必要なのか？

本稿執筆時点では、Rust にはまだ公式な言語標準や仕様がありません。 C や C++ の ISO 文書に相当する Rust の文書はありません。 そのため、断定的な主張をするのは困難です。

The Rust Reference には、Rust において未定義と見なされる振る舞いの非網羅的な一覧が含まれており⁷、それらはいずれも導入するには unsafe キーワードが必要です。 したがって、Rust における UB の潜在的な発生源は、おそらく次の 3 つだけです。

• 不変条件が実際には維持されていない unsafe 関数またはブロック（私たちの責任）。これには、サポートされていない ABI で外部例外が FFI 境界を越えるような、FFI のエッジケースも含まれます。

• 健全性を脅かすまれなコンパイラバグ⁸（発見され次第パッチ適用）。

• 特定の CPU 拡張のサポートを有効にしてコンパイルされたプログラムを、それらをサポートしていない CPU バリアント上で実行するような、プラットフォーム固有の不変条件違反（デプロイの問題）。

2022 年 7 月、Ferrocene Language Specification（FLS）⁹ が公開されました。 この仕様は、特定の安全クリティカルな用途向けに認定された Rust コンパイラの商用ダウンストリームである Ferrocene をサポートします。 この仕様は Rust 言語と標準ライブラリ全体を文書化することを目的としていませんが、現在のところ Rust プログラムにおける UB の発生源になり得るものを 21 個列挙しています¹⁰。

第 12 章では、Rust プログラムの UB を検出するための実験的な動的ツールである miri¹¹ を使用します。

Rust の利点をより実感しやすくするために、バグのある C プログラムを Rust に移植してみましょう。

fn undef_func() -> isize {
    let uninit_var: isize;
    if uninit_var > 0 {
        return 1;
    } else {
        return 0;
    }
}

fn main() {
    println!("{}\n", undef_func());
}

cargo build を実行すると、次のようになります。

error[E0381]: use of possibly-uninitialized variable: `uninit_var`
 --> src/main.rs:3:8
  |
3 |     if uninit_var > 0 {
  |        ^^^^^^^^^^ use of possibly-uninitialized `uninit_var`

For more information about this error, try `rustc --explain E0381`.

gcc の警告も同様でしたが、それに従うかどうかは完全に任意でした。 Rust では、この同じ誤りはハードエラーです。この問題に対処しない限り、プログラムはコンパイルされません。 言い換えれば、すべての安全な Rust プログラムは前述の MISRA C Rule 9.1 に従います。

より一般的に言えば、安全な Rust プロジェクトのコンパイルに成功するということは、UB が排除されている可能性が高いことを意味します。 したがって、以下に従うことで、大きな保証が得られます。

[RR, Directive 2.1] プロジェクト全体がエラーなしでコンパイルされるべきである⁵

なぜ UB はそもそも存在するのか？

商用かオープンソースかを問わず、ある言語に複数のコンパイラが存在することが望ましいと仮定しましょう。 各コンパイラ実装は、異なるニッチに対応したり、独自の機能を提供したり、あるいは単に有望なアイデアを実験したりするかもしれません。 これは、同じ標準やプロトコル（HTML、HTTP2 など）をすべてサポートする複数の Web ブラウザーが存在するのと同じです。

したがって、単一の言語標準（すでに触れた ISO C 標準² のようなもの）は、任意のプラットフォームアーキテクチャを対象とする任意のコンパイラ実装に適用可能である必要があります。 これはインターフェイス設計の問題に似ています。 失敗モードを設計することを伴い、そこで UB が登場します¹²。これは、標準が普遍的な規則を課さない、課すべきでない、または課せないエッジケースを「処理」する 1 つの方法です。

そのため、標準は境界を引きます。つまり、さまざまな基盤ハードウェアを表現するのに十分一般的な「抽象機械」を定義します。 これには、コンパイラ開発者にプラットフォーム固有の最適化を導入する余地を与えるという利点があります。 これはコンパイラの主な仕事の 1 つです。つまり、効率的な機械語コードを生成するために、書き換え規則を繰り返し適用することです。

最適化コンパイラは、入力ソースコードが言語仕様に従って UB を導入しないと仮定します。 この仮定が次の場合：

• 真（ソースが実際に UB を含まない） - 書き換え規則は既存のコードを、より高速で、かつ論理的に同等な新しいコードに置き換えます。

  • これらの規則は、抽象的な仕様が提供する「自由度」を利用して、アーキテクチャ固有の命令やメモリモデルのセマンティクスを活用することがよくあります。あるいは、不要であることが証明されるチェックを削除します¹³。

• 偽（ソースに UB が含まれる） - 書き換え規則の適用によって論理的矛盾が生じる可能性があります。

  • 存在する UB が「トリガー」された場合、結果として不正なコード置換や任意の実行時操作が発生します。

この二分法から、次の疑問が生じます。十分に「賢い」コンパイラであれば、UB を含まないソースであるという仮定を単純に検証できないのでしょうか？ 構文や型付けをコンパイル時にチェックするのと同じように。

答えはイエスです！ ほのめかしたように、完全に安全な Rust コードをコンパイルするときに rustc が行っているのは、まさにそれです¹⁴。 高度な型システムと実行時チェック挿入の組み合わせを使用します。

しかし、すべての UB が存在しないことを自動的に保証するのは、C、C++、そして unsafe Rust にとって技術的に実現困難です。 さらに、最も安全な Rust プログラムであっても、C の libc や Rust の core の一部のように、内部で何らかの unsafe コードにリンクしている可能性があります¹⁵。 保証の観点からは、そのように広く使われ、十分に検証された依存関係は、私たち自身が書く unsafe コードよりも UB を含む可能性が低い、ということに賭けているのです。

最適化の例は何か？

John Regehrは2017年の講演¹²で説得力のあるスニペットを示しました。ここではそれを少し変更して使います。 次の関数があるとします。

int set(int* a, int* b) {
   *b = 3;
   *a = 7;
   return *b;
}

aとbは同じ型intへのポインタであり、エイリアスする可能性があります（ポインタとエイリアシングについての第2章の議論を思い出してください）。 つまり、この関数は、ポインタがエイリアスしない場合は3を返し、エイリアスする場合は7を返すべきです。

したがって、コンパイラは整数を返す前にメモリからロードする機械語コードを生成せざるを得ません。 エイリアスする場合としない場合の両方に対応するには、最新のデータを読み取る必要があります。 次のようなx86-64アセンブリのスニペットが出力される可能性があります（ATT構文）。

set:
  movl $3, (%rsi)
  movl $7, (%rdi)
  movl (%rsi), %eax

x86アセンブリに詳しくない場合、ここでの重要な考え方は、最後の行がメモリアドレスからのロードであるということです。

• %rsiはポインタを保持するレジスタです。

• (%rsi)はポインタの参照外しであり、そのポインタが指すデータを読み取ります。

• movl (%rsi), %eaxは読み取ったデータを、戻り値に使われるレジスタである%eaxへコピーします¹⁶。

では、2つのパラメータが異なる整数型へのポインタであるとします。

int set(long* a, int* b) {
   *b = 3;
   *a = 7;
   return *b;
}

この場合、コンパイラはC標準における「strict aliasing」の定義に基づき、ポインタがエイリアスしないと仮定できます。 もはやメモリから現在の値を読み取る必要はなく、定数3を返せます。 その方が高速です。 この最適化により、次のようなアセンブリになる可能性があります。

set:
  movl $3, (%rsi)
  movq $7, (%rdi)
  movl $3, %eax

すばらしいことに、より効率的なコードが得られました。 最後の命令には読み取りがなく、定数の移動だけです。

では何が問題なのでしょうか？ Cプログラマは、関数を呼び出す前にint*をlong*へキャストすることで、その仮定を破ることができます。 以下のプログラムの動作は未定義です。

include <stdio.h>

int set(long* a, int* b) {
    *b = 3;
    *a = 7;
    return *b;
}

int main() {
    int x = 0;
    printf("%d\n", set((long*)&x, &x));
}

さまざまな理由から、キャストはCおよびC++プログラムで一般的な操作です。 Linuxカーネルのようなプロジェクトでは、安全性のためにこの特定の最適化を明示的に無効化しています⁴。

安全なRustでは、参照をキャストできません。また、可変エイリアシングが常に存在しないことを保証できます。 そのため、この特定のケースでは、RustはUBの危険なしに最適化を実行できます。

UBの実際の影響は何か？

起こり得る結果は4つあります¹²。 おおむね最善のケースから最悪のケースの順に列挙できます。

1. プログラムが即座に壊れる: 実行時にクラッシュ（例: セグメンテーションフォルト）または例外（例: ゼロ除算の試行）が発生し、プログラムは停止します。

   • 製品を出荷する前に検出するのが最も簡単なケースです。動的テストで、欠陥のあるコードパスを一度実行するだけで済みます。

2. プログラムが破損した状態で実行を継続する: 内部状態が論理的に無効になりますが、プログラムは実行を続けます。何らかの任意の条件が満たされた場合に後でクラッシュすることもあれば、単に終了するものの誤った結果を生成することもあります。

   • このケースは検出がより困難であり、発見するにはより徹底したテストケースが必要になる場合があります。

3. UBに依存しているにもかかわらず、プログラムが期待どおりに動作する: テストの観点からはプログラムが正しく見えますが、そのUBは起動を待つ「時限爆弾」です。別のアーキテクチャ向けにコンパイルしたり、新しいコンパイラを使ったり、単に異なる設定を使ったりすると、プログラムは動作しなくなる可能性があります。

   • 検出にはビルドツールチェーンの変更または更新が必要です。また、UBが上記のケース2として現れる場合、検出は即時ではない可能性があります。

4. プログラムが攻撃に対して脆弱になる: 想定された入力ではプログラムはUBを引き起こしませんが、攻撃者が特別に細工した入力を与えると引き起こします。メモリ破壊バグの悪用にはUBを引き起こすことが伴います（次章で見ます）。

   • これは最悪のシナリオです。攻撃者が、私たちのテストでは見つけられなかったUBを検出し、それを利用して本番環境の資産を侵害します。

UBの最初の3つの潜在的な影響は、機能性と信頼性への脅威です。 4つ目はセキュリティへの脅威です。 そのため、MISRA C標準には次の広範なルールが含まれています。

[AR, Rule 1.3] 未定義動作の発生をすべて排除する⁵

Rustの設計により、一般にこのルールへ準拠しやすくなります。 開発者は、何百もの難解なUBのエッジケースを同時に覚え、それらを100万行規模のコードベース全体で失敗なく適用する責任を負いません。 代わりに、Rustコンパイラが潜在的な問題をチェックします。 自動的に、かつ正確に。

要点

私たちが持つ最良のツールでも、中規模のCまたはC++コードベースに存在するすべての未定義動作を正確に突き止めることはできません。

• 商用の静的解析ツールは偽陽性に悩まされます。実用的な結果は多くの場合、ノイズの中に埋もれます。さらに、多くのUBについては検出アルゴリズムを設計すること自体が困難です。第2章で思い出したかもしれませんが、エイリアシングのような静的解析における重要な問題は、数学的に決定不能です。

• 動的ツール（LLVMのオープンソースであるUBSan¹⁷、ASan¹⁸、TSan¹⁹など）は近年大きく改善されましたが、それでも動的テストの根本的な制限（プログラムの状態空間のごく小さなサンプル）によりバグを見逃します。カバレッジガイド付きファジング（第12章で紹介）と組み合わせた場合でさえもです。

これこそが、MISRA Cのような標準が存在する理由の一部であり、また数え切れないほどのエンジニアリング時間が、これらの標準が守られることを保証するために費やされている理由でもあります。

欠陥率の削減は困難な戦いです。 CとC++がそれぞれの標準で許している未定義動作の量が非常に多いことを考えると、それは消耗戦だと主張することもできます。 勝者は信じられないほどのエンジニアリングコストを支払います。ツールのライセンス、出荷を遅らせるプロセス、そしてデバッグに費やされる人時という形でです。 あるいは、UBが悪用可能な脆弱性につながる場合には、サービス停止という形で支払うことになります。

それでは、Rustの安全なサブセットを学び始めましょう！ Rustは完璧ではありませんが、UBを排除することは確かにRustの強みです。

gcc はまだ戦いを諦めていない！

弱い型システムと、UB の多い明文化された仕様を前提にすると、C コンパイラのメモリ安全性に関する保証の上限は低いと私たちは考えています²⁰。 しかし、重要な進歩は今も続いています。 そして、C が広く使われていることを考えると、どんな小さな進歩にも大きな影響があります。

gcc 12 は、改善された実験的な静的テイント解析²¹（信頼できないデータのフロー追跡）を提供します。 ソースアノテーションと組み合わせることで、潜在的な攻撃の入口を体系的にレビューする方法になります。 そして、これは現時点で rustc には提供されていない高度な機能です。

この同じバージョンでは、新しい -Wanalyzer-use-of-uninitialized-value フラグ²¹ も追加されています。 上で -Wall を使ったことで含まれていた -Wuninitialized 警告とは異なり、この新しいフラグは、関数間のフローに対して分岐を考慮した静的解析を使用します。 これは、誤検知を減らし、かつ、より対処可能な警告を増やすことを意味するかもしれません。

私たちは、前述の「Dirty Pipe」⁶ カーネル脆弱性を検出する gcc 12 の能力はテストしていません。 しかし、関心のある読者にとっては、試してみる価値のある演習かもしれません。

1. Misra C コーディング標準と開発におけるその役割（SAS Talk）. Roberto Bagnara (2018). ↩

2. ISO/IEC 9899:TC3. International Organization for Standardization (2007). C 言語のより新しい標準は有料であり、オンラインで自由に入手できるものではないことに注意してください。本書で述べる点は、より新しい C 標準にも依然として適用できます。 ↩ ↩2 ↩3 ↩4

3. nasal demons. 悪名高い Usenet の投稿によれば、UB の任意の結果には「鼻から悪魔が飛び出す」ことも含まれ得ます。そのため、UB は時々冗談めかして「nasal demons」と呼ばれます。 ↩

4. 未定義動作：私のコードに何が起きたのか？. Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, M. Frans Kaashoek (2012). ↩ ↩2

5. MISRA C: 2012 クリティカルシステムにおける C 言語の使用に関するガイドライン（第 3 版）. MISRA (2019). ↩ ↩2 ↩3

6. Dirty Pipe 脆弱性. Max Kellerman (2022). ↩ ↩2 ↩3

7. 未定義と見なされる動作. The Rust Reference (Accessed 2022). ↩ ↩2

8. Pin における健全性の欠如. comex (2019). ↩

9. Ferrocene 言語仕様. Ferrous Systems (2022). ↩

10. 未定義動作の一覧. Ferrous Systems (2023). ↩

11. miri. Ralf Jung (Accessed 2022). ↩

12. CppCon 2017: 「2017 年の未定義動作」. John Regehr (2017). ↩ ↩2 ↩3

13. 未定義動作はもっとよい評判に値する. Ralf Jung (2021). ↩

14. この主張には、議論の余地がある境界事例があるかもしれません。たとえば、Cargo.toml で overflow-checks = false が指定されている場合（最適化された release プロファイルのデフォルト設定）、整数オーバーフローは実行時に発生し得ます。これは、C/C++ におけるものとは異なり、Rust では技術的には UB ではありません。2 の補数によるラップを確実に期待できるからです。しかし、それでも、より大きなアプリケーションの文脈では予期しないバグを引き起こす可能性があります。 ↩

15. Rust Core ライブラリ. The Rust Team (Accessed 2022). ↩

16. 技術的には、%eax は x86-64 システムにおける 8 バイトの %rax レジスタの下位 4 バイトです。%rax は戻り値に使用されます。この例では、8 バイトポインタを逆参照していますが、4 バイト整数を返しています。 ↩

17. UndefinedBehaviorSanitizer. LLVM Project (Accessed 2022). ↩

18. AddressSanitizer. LLVM Project (Accessed 2022). ↩

19. ThreadSanitizer. LLVM Project (Accessed 2022). ↩

20. 一方で、C コンパイラは安全認証の観点から成熟しており、よく理解されています。また、形式検証の面でもさらに先を進んでいます。一例として、CompCert²² C コンパイラは、ソースコードのセマンティクスが機械語コードのセマンティクスと一致することを証明します。現行の Rust コンパイラで、そのレベルまたは種類の保証を主張できるものはありません。 ↩

21. GCC 12 コンパイラにおける静的解析の現状. David Malcom (2022). ↩ ↩2

22. CompCert. Xavier Leroy (Accessed 2022). ↩

Rust: 低レベルデータ（全6回中1回目）

ここまで、静的保証の文脈で Rust の型システムについて議論してきました。 具体的には、可変エイリアシングの防止と UB の排除です。

しかし、日々の開発の大半においては、これらは副次的な利点だと主張することもできます。 そして、Rust の型システムの真の価値は、その表現力、つまり問題領域を柔軟な構成要素に対応付ける能力にある、と。

このような議論はすぐに主観的なものになるため、Rust については時間をかけて自分自身の意見を形成すべきです。 とはいえ、プログラミング上の問題を解く最初の一歩は、通常、処理するデータを表現することです。 そこで、Rust が提供する選択肢をいくつか見ていきます。

プリミティブ型

Rust のプリミティブ型は、あなたがよく知っているほぼどのプログラミング言語とも似ています。一般的なブール値、整数、浮動小数点数、文字、文字列などがあります。

高水準のインタープリター型言語と比べた場合の重要な違いの1つは、整数と浮動小数点数が固定幅であることです。 これは高性能なシステム言語の特徴であり、個々の数値は（Python のように）ヒープメモリ上の構造体としてではなく、（C のように）CPU レジスタに格納される必要があります。

このハードウェアレベルの関心事には、境界のある範囲とホスト固有の幅という、2つの重要な含意があります。

1) 境界のある数値範囲

Rust には12個のプリミティブな数値型があります。

• 符号なし整数型が5つ: u8、u16、u32、u64、u128、および usize。

• 符号付き整数型が5つ: i8、i16、i32、i64、i128、および isize。

• IEEE 準拠の浮動小数点数が2つ: f32（少なくとも10進6桁の精度）と f64（少なくとも10進15桁）。

型名の接尾辞はビット幅を示します。たとえば u128 は幅が128ビット（16バイト）です。 重要な含意は次のとおりです。ある整数型が表現できる値の範囲は有限です。 上限と下限は、符号の有無と幅の両方によって決まります。 以下の表を見てください（網羅的ではありません）。

Rust の標準ライブラリは、上限と下限のための便利な制限定数を提供しているため、これらの範囲をそらで覚えたり、網羅的な表を参照したりする必要はありません。

assert_eq!(0, u8::MIN);
assert_eq!(255, u8::MAX);

型の範囲を超えると「ラップアラウンド」が発生します。 まれに、それが望ましい動作である場合もあります。 私たちは RC4 暗号の実装時に、剰余算術をシミュレートするため wrapping_add を慎重かつ意図的に使用しました。 これがどのように機能するかを示すために、u8 の上限である 255 を超えた場合に何が起こるかを考えてみましょう。

let x: u8 = 200;
let y: u8 = 100;

assert_eq!(x.wrapping_add(y), 44);

44 は 300 % 256、つまり全体を範囲サイズで割った余りです。 暗号の文脈以外では、サイレントなラップアラウンドは 整数オーバーフロー のバグと見なされます。 もし 200 が銀行口座のドル残高を表し、口座の所有者がさらに 100 ドルを預け入れたなら、レシートに 44 の口座残高が表示されていて驚くことでしょう！

ここで、Rust におけるいくつかの微妙な点に踏み込みます。 assert_eq!(x.wrapping_add(y), 44); の代わりに assert_eq!(x + y, 44); と書いていた場合、プログラムはオーバーフローを警告するエラーを吐き出していたでしょう。

error: this arithmetic operation will overflow
 --> src/main.rs:8:12
  |
8 | assert_eq!(x + y, 44);
  |            ^^^^^ attempt to compute `200_u8 + 100_u8`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

ここでは、x と y の両方が定数であるため、オーバーフローをコンパイル時に検出できたという意味で運が良かったのです。 Rust は、値が事前には分からない変数については、オーバーフローを捕捉するために任意のランタイムチェックを使用します。この話題には、安全性について詳しく議論する第4章で戻ってきます。

Rust の整数オーバーフローについて、もう1つ覚えておくべき詳細があります。C/C++ とは異なり、それは UB の潜在的な原因ではありません。 ラップアラウンドの規則は明確に規定されており、ターゲットプラットフォーム全体で普遍的です¹。

2) ホスト固有の整数

usize 型と isize 型は、それぞれ符号なし整数と符号付き整数ですが、対応する他の型のようにビット幅を指定していないことに気づいたでしょう。 それは、それらのサイズがプログラムのコンパイル先となる特定のマシンに依存するためです。

どちらも、32ビットシステム向けにコンパイルする場合は4バイト長であり、現代的な64ビットシステムでは8バイト長です。 理論上は、128ビットシステムであれば16バイト長にもなり得ますが、商用プロセッサで128ビットアーキテクチャを使用しているものはありません。

範囲とオーバーフローについて述べたことを踏まえると、マシン依存（別名ホスト固有）の型は曖昧だと感じるかもしれません。 危険ですらあるかもしれません。 MISRA によれば、その認識は正しいです。

[RR, Directive 4.6] サイズと符号の有無が明示された数値型を使用する²

Rust では可能な場合に明示的な数値型を使用できますが、インデックス指定は例外です。コレクションのインデックス指定には usize 型が必要です（たとえば my_vec[i] = j では、i は usize でなければなりません）。 これは、内部的にはコンテナーへのインデックス指定にメモリアドレスの計算が関わることが多いためです³。 そして、アドレスの幅はターゲットマシンに依存します。

現在の Rust では、u64 のような明示的な数値型から usize へキャストできます。 おそらく、上記の MISRA ルールの精神に従うために、インデックス指定の前にこの操作を行う必要があるでしょう。

数値型間のキャストは、Rust が型キャストを許可するごく少数のケースの1つです。 これは別のルールにも役立ちます。

[AR, Rule 11.3] ある型への参照から別の型への参照へキャストしてはならない²

Rust では、トレイト という概念を介して、型間（参照間ではありません）の安全で明示的な変換を許可しています。具体的には、From⁴ と Into⁵ と呼ばれるトレイトです。 次のセクションでトレイトを説明し、後の章で From を使用します。

型推論

Rust は強く静的に型付けされます。 すべての値はコンパイル時に既知の型を持ちます。 ジェネリックパラメーターでさえそうです。その最終的な型はコンパイル中に決定されます（これについては後で詳しく説明します）。

古い静的型付け言語とは異なり、Rust は特定の場合に式の型を自動的に検出するために 型推論⁶ を使用します。経験則として、型注釈を明示的に書き出すことは次のとおりです。

• 関数シグネチャ（例: パラメーターや戻り値の型）、グローバル変数、またはエクスポートされる型（例: ライブラリの公開 API の一部）では、常に必須です。

• 関数本体の中では、ときどき必須です。

次の例を考えてみましょう。

#![feature(type_name_of_val)]
use std::any::type_name_of_val;

fn sum(x: u128, y: u128) -> u128 {
    x + y
}

fn main() {
    let a = 1;
    let b = 3;
    let c = sum(a, b);

    println!("a is a {} with value {:?}", type_name_of_val(&a), a);
    println!("b is a {} with value {:?}", type_name_of_val(&b), b);
    println!("c is a {} with value {:?}", type_name_of_val(&c), c);

    let mut list = Vec::new();
    list.push(a);
    list.push(b);
    list.push(c);

    println!("list is a {} with value {:?}", type_name_of_val(&list), list);
}

このスニペットは次のように出力します。

a is a u128 with value 1
b is a u128 with value 3
c is a u128 with value 4
list is a alloc::vec::Vec<u128> with value [1, 3, 4]

ここでは自動推論が 2 回発生しています。

まず、プリミティブ型が関数シグネチャから推論されました。 もし関数 sum がプログラムの一部でなかったなら、let a = 1; は let a: i32 = 1; と等価になります。 4 バイトの符号付き整数である i32 は、Rust のデフォルト整数型です。 しかし、let c = sum(a, b) という行があるため、コンパイラーは a が実際には 16 バイトの符号なし整数である u128 だと判断しました。

次に、動的コレクションの型が、格納された要素の型から推論されました。 以下の 3 つの文はすべて等価です。

• let mut list = Vec::new(); - 推論された型（上記と同様）。
• let mut list: Vec<u128> = Vec::new(); - 明示的な型注釈。
• let mut list = Vec::<u128>::new(); - 明示的なコンストラクター。

この便利な推論による短縮記法を使えたのは、サンプルプログラムに少なくとも 1 つの list.push() 文があったからです。 コンパイラーはベクターにプッシュされる要素の型、この場合は u128 整数を見て、ベクターの型を決定しました。

異種コレクションについてはどうでしょうか？

変化はあるものの論理的に関連する型の要素をベクターに格納したい場合、型推論に頼ることはできません。 dyn キーワードと「トレイトオブジェクト」と呼ばれるものを明示的に使う必要があります。 これは、この本で必要になったり扱ったりする言語機能ではありません。

タプル vs. 配列

Rust は、順序付きで固定サイズの値のシーケンスを表す方法として、タプルと配列の 2 つを提供します。

• タプルは、異なる型の複数の値をグループ化できますが、定数でしかインデックス指定できません。

• 配列は、同じ型の複数の値だけをグループ化できますが、変数でインデックス指定できます。

タプル

どちらをいつ使うべきかについて厳密な規則はありませんが、タプルは戻り値の型として特に便利です。 関数が複数の値を返すべき場合に使います。

[少し不自然な] 例: 最短辺に基づいて 30-60-90 三角形（特殊な「直角三角形」⁷）の各辺の長さを計算する必要があるとします。 既知の公式があります。

// 辺の比率は 1 : 2 : square_root(3)
fn compute_30_60_90_tri_side_len(short_side: f64) -> (f64, f64, f64) {
  (
    short_side,
    short_side * 2.0,
    short_side * 3_f64.sqrt() // "_f64" は省略可能な型接尾辞構文
  )
}

fn main() {
  let tri_sides = compute_30_60_90_tri_side_len(10.0);

  // タプルの定数インデックス指定
  assert_eq!(tri_sides.0, 10.0);
  assert_eq!(tri_sides.1, 20.0);
  assert_eq!(tri_sides.2, 17.32050807568877);

  // タプルの分配束縛
  let (a, b, c) = compute_30_60_90_tri_side_len(10.0);

  assert_eq!(a, 10.0);
  assert_eq!(b, 20.0);
  assert_eq!(c, 17.32050807568877);
}

関数 compute_30_60_90_tri_side_len は 3 つの値、つまり三角形の 3 辺の長さを返します。 この関数を最初に呼び出したとき、変数 tri_sides に推論される型は (f64, f64, f64) です。 各浮動小数点数には定数位置でアクセスできますが、変数ではアクセスできません（例: tri_sides.1 は機能しますが、tri_sides.i や tri_sides[i] は機能しません）。

名前付きフィールドを持つ構造体を定義することもできましたが、タプルは簡潔な短縮記法を提供します。 そして、compute_30_60_90_tri_side_len の 2 回目の呼び出しで示している、分配束縛と呼ばれる手法で名前を設定できます。 単一のタプル変数に代入する代わりに、分配束縛を行い、各タプル要素をそれぞれ独自の名前付き変数（例: a、b、c）に代入します。

配列

配列は、他のプログラミング言語でもおそらく見たことがある汎用データ構造なので、ここでは深く掘り下げません。 Rust における配列宣言の構文は [T; N] です。 格納される各値の型は T で、N は配列の長さです。 次のように動作します。

// 明示的な配列型宣言
let numbers: [u64; 3] = [42, 1337, 0];

// 推論された配列型（`[&str; 4]`、読み取り専用文字列参照の配列）
let operating_systems = ["Linux", "FreeBSD", "Tock", "VxWorks"];

// すべての要素（1,000 個）を単一の値（0）で初期化
let mut buffer = [0; 1_000];

// インデックスベースの書き込みアクセス
for i in 0..1_000 {
  assert_eq!(buffer[i], 0); // ゼロ初期化されているはず
  buffer[i] = i; // 新しい値で上書き
}

assert_eq!(buffer[0], 0);
assert_eq!(buffer[1], 1);
assert_eq!(buffer[2], 2);

// イテレーターベースの書き込みアクセス
for num in buffer.iter_mut() {
  *num += 7; // "*" は書き込みのためのデリファレンス
}

assert_eq!(buffer[0], 7);
assert_eq!(buffer[1], 8);
assert_eq!(buffer[2], 9);

上記では、2 つのループを使って 1,000 要素の配列の内容を変更しています。 1 つ目は従来のインデックスベースのアクセス（例: buffer[i]）を使っています。 2 つ目はイテレーター（例: buffer.iter_mut()）を使って同様の操作を実行しています。

イテレーターは、map や filter のような関数型プログラミングの構成要素を可能にします。 多くの言語ではそれに性能上のペナルティが伴いますが、慣用的な Rust ではこれらの構成要素がよく使われているのを目にするでしょう。 実際にはより高速なコードにつながる可能性があるからです。

なぜでしょうか？ 上記の 1 つ目のループには暗黙の契約があります。i は配列の長さより小さくなければなりません。 そうでなければ、配列の末尾を越えて範囲外書き込みを行うことになります。 安全性を確保するため、コンパイラーは 1 つ目のループに実行時の境界チェックを追加しなければなりません（ただし 2 つ目には追加しません）。 そのチェックにはコストがあります。 この章の後半でエラーハンドリングについて説明するときに、このチェックに失敗するとどうなるかを見ていきます。

配列 vs. ベクター

型推論について説明したときに要素を追加した Vec とは異なり、配列は動的に拡張できません。 その容量は固定されています。 この制約は不便な場合がありますが、配列をポータブルにします。配列を使うために動的メモリアロケーション用のランタイムライブラリに頼る必要がありません。

Rust と C の配列における大きな違いの 1 つは、前者では長さが型の一部として明示的にエンコードされることです。 これにはいくつかの利点があり、その 1 つが次への準拠です。

[AR, Rule 17.5] 関数パラメーターとして使用される配列は、正しい数の要素を持たなければなりません²

参照

前の章では、整数をインクリメントする関数の文脈で、すでに参照を紹介しました。 参照は生ポインターに代わる現代的な手段です。

```rust,noplaypen
fn incr(a: &mut isize, b: &isize) {
    *a += *b;
}

fn main() {
  let mut x = 3;
  let y = 5;

  incr(&mut x, &y);

  assert_eq!(x, 8);
  assert_eq!(y, 5);
}

参照はシステムプログラミングに不可欠です。 参照は、値渡し（値全体をコピーする）の代わりに、参照渡し のセマンティクス（「ポインター」を渡す）を可能にすることを思い出してください。 このレベルの制御は不可欠であり、大きな値を高性能に操作できるようにします。 プログラマーは、いつ シャローコピー（参照のみを複製する）を行い、いつ ディープコピー（すべてのデータを複製する）を行うかを選択できます。 前者は、バイトのコピーに費やす時間が少なくなり、使用される総メモリ量も少なくなることを意味します。

この章の後半で所有権について説明するときに、参照の話題に戻ります。 所有権エラーを扱うと、Rust がこの MISRA ルールを強く推奨していることにすぐ気づくでしょう。

[AR, Rule 8.13] 参照は、可能な限り不変であるべきです²

スライス

スライスは参照と密接に関連する概念であり、これも不変と可変のバリアントがあります。

• &[T] は、T の不変な共有スライスです。

• &mut [T] は、T の可変な排他的スライスです。

どちらのスライス型も、何らかの別の、より大きな値の中に格納されている値のシーケンスへの「部分的なビュー」です。 例を使って、この文の意味を理解しましょう。

// 5項目の配列
let mut buffer_overflow_defenses = [
    "stack canary",
    "ASLR",
    "NX bit",
    "CFI",
    "Intel CET",
    "ARM MTE",
];

// 最初の3つの不変スライスを作成
// [..=2] は包括的な範囲記法で、[..3] と等価
let basic_defenses = &buffer_overflow_defenses[..=2];

assert_eq!(basic_defenses, &["stack canary", "ASLR", "NX bit"]);

// 最後の2つの可変スライスを作成
let advanced_defenses = &mut buffer_overflow_defenses[4..];

assert_eq!(advanced_defenses, &mut ["Intel CET", "ARM MTE"]);

// スライス経由で変更
advanced_defenses[1] = "safe Rust!";

// スライスとその「バッキングストレージ」の両方が更新されることに注目
assert_eq!(advanced_defenses, &mut ["Intel CET", "safe Rust!"]);
assert_eq!(buffer_overflow_defenses[5], "safe Rust!");

より大きなシーケンスを部分分割することは、上で示したように、スライスの便利な使い方の1つです。 前の章でも、スライス範囲記法（例: [..=2] や [3..]）を見たことを思い出すかもしれません。 これは IETF テストベクトルの検証で、RC4 キーストリームから 16 バイトのチャンクを取り出すために使いました。

スライスは、イディオマティックな API を作成する際にも役立ちます。 RC4 関数（new や apply_keystream など）のパラメーターを定義するときにこのアプローチを活用しましたが、その根拠については詳しく説明しませんでした。 以下を考えてみましょう。

fn count_total_bytes(byte_slice: &[u8]) -> usize {
    let mut cnt = 0;

    // アンダースコアは未使用変数を示す
    for _ in byte_slice {
        cnt += 1;
    }

    // おっと - ループする必要はなかった。組み込みの長さ取得メソッドがある！
    assert_eq!(cnt, byte_slice.len());

    cnt
}

fn main() {
    let byte_arr: [u8; 4] = [0xC, 0xA, 0xF, 0xE];

    // Vec初期化の短縮記法
    let mut byte_vec = vec![0xB, 0xA, 0xD];

    // 動的にさらにデータをプッシュ
    byte_vec.push(0xF);
    byte_vec.push(0x0);
    byte_vec.push(0x0);
    byte_vec.push(0xD);

    // どちらの型も &[u8] として借用できることに注意
    assert_eq!(count_total_bytes(&byte_arr), 4);
    assert_eq!(count_total_bytes(&byte_vec), 7);
}

パラメーターシグネチャでスライスを使う利点は、さまざまな種類のコレクションを スライスとして借用 できることです。 上の例では、バイトの動的ベクターとバイトの固定サイズ配列の両方で動作する関数を1つ書きました。

最後に、文字列（String 型）と文字列スライス（&str 型）の関係に触れないわけにはいきません。 このトピックを適切に議論するにはかなりの複雑さが伴い、また文字列は、この本で書くコードには特に関係しません。 私たちが構築するデータ構造はもちろん文字列を格納できますが、詳細な議論は省き、興味がある場合は公式 Rust book⁸ の 8.2 節「Storing UTF-8 Encoded Text with Strings」をお勧めします。

vec! マクロ

上のコードには、要素のベクターを初期化するための短縮記法が含まれています。 let mut byte_vec = vec![0xB, 0xA, 0xD]; は、次と等価です。

let mut byte_vec = Vec::new();
byte_vec.push(0xB);
byte_vec.push(0xA);
byte_vec.push(0xD);

実際、上の main 関数は、次のようにすれば push 呼び出しを完全に避けることもできました。

let mut byte_vec = vec![0xB, 0xA, 0xD, 0xF, 0x0, 0x0, 0xD];

この構文は byte_arr の初期化に似て見えるかもしれませんが、両者を混同しないでください。配列は固定容量を持つため、初期化後に新しい項目を配列へ push することはできません。

まとめ

プリミティブ（整数に焦点を当てました）、タプル、配列、参照、スライスについて簡単に取り上げました。 そしてその過程で、型推論の感覚もつかみました。 これで、Rust でデータを表現し操作するための低レベルな手法を見てきたことになります。

細かな複雑さにさらに何十ページも費やす代わりに、この言語のより刺激的で興味深い機能、つまりより高レベルな構造を表現する方法へ進みます。

本書を読み進めながら実践経験を積むことで、これらすべてのトピックを習得していくことになります。 現在の目標は、Rust の基礎をすばやく概観することです。

1. Myths and Legends about Integer Overflow in Rust. Huon Wilson (2016). ↩

2. MISRA C: 2012 Guidelines for the use of the C language in critical systems (3rd edition). MISRA (2019). ↩ ↩2 ↩3 ↩4

3. ええ、Vec の場合はそれが当てはまります。内部的には、Vec はヒープ上に割り当てられた配列への ファットポインター（メモリアドレス、長さ、容量）です。my_vec[i] によるインデックスアクセスでは、メモリ位置へのオフセットを計算します。しかし、自分で定義するカスタムコンテナーでは、インデックス演算子をオーバーロードすることで、そのコンテナーの文脈で論理的に意味のある任意の操作を実行できます。本書の後半で、順序付きマップとセットのために独自のインデックスアクセスロジックを実装します。 ↩

4. Trait std::convert::From. The Rust Team (Accessed 2022). ↩

5. Trait std::convert::Into. The Rust Team (Accessed 2022). ↩

6. Type inference. Guide to Rustc Development (Accessed 2022). Rust は Hindley-Milner 型推論アルゴリズム⁹を拡張したものを使用します。 ↩

7. 30° - 60°- 90° Triangle. Math Open Reference (Accessed 2022). ↩

8. 文字列で UTF-8 エンコードされたテキストを格納する。Steve Klabnik、Carol Nichols 著（2022年参照）。 ↩

9. Hindley–Milner type system. Wikipedia (Accessed 2022). ↩

Rust: 高レベルデータ（全6回中2回）

前のセクションでは、低レベルの基礎を見てきました。 それらは重要であり、一般的です。 しかし、Rust が本当に輝き始めるのは、より高レベルの構成要素、つまり問題領域により密接に対応する「カスタム」データ型です。

Rust は、ML、OCaml、Haskell などの関数型言語から影響を受けています¹。 Rust は、興味深く、おそらくエキゾチックとも言える構成要素をいくつかもたらしています。 高性能なシステム言語ではあまり見かけない機能です。

このセクションでは、関数型言語に関する事前知識がないことを前提に、これらの構成要素のいくつかに少しずつ慣れていきます。

列挙型

列挙型、略して「enum」は、取り得る値が名前付き定数の集合である型を定義できるようにします。 最も基本的な使い方では、Rust の enum は他のほとんどの言語に存在する enum と似ています。

これからいくつかのセクションにわたって、実行例として、複数のプロセス（メモリ上に存在する、プログラムの分離されたインスタンス）を実行できるオペレーティングシステム（OS）を使います。 Rust コードの構成要素が特定の領域にどのように対応できるかを示すためです²。 そして、その過程でいくつかの OS の概念を学ぶ、または復習します。

あるプロセスは、任意の時点で次の 3 つの状態のいずれかにあると仮定しましょう。

1. Running - 現在 CPU コア上で実行中。

2. Stopped - 無期限に一時停止中（たとえば、ユーザーが Ctrl+Z を押した可能性があります）。

3. Sleeping - 一時的に停止中（たとえば、ユーザー入力のようなデータが利用可能になるのを待っている可能性があります）。

enum は、相互に排他的でありながら関連する可能性を表現する自然な方法です。 3 つのバリアント（名前付き定数 Running、Stopped、Sleeping）を持つ State enum を宣言できます。

pub enum State {
    Running,
    Stopped,
    Sleeping,
}

OS は、プロセスが現在どの状態にあるかに応じて異なるアクションを取る必要があります。 たとえば、内部タイマーが切れたとき（例: 「割り込みが発生する」）、現在実行中のプロセスを停止し、その状態を保存し、別のプロセスを実行または復元するタイミングかもしれません。 CPU 時間は共有リソースであり、プロセスは順番に使う必要があります。

Rust は、どのロジックを実行すべきかを条件付きで決定する手段として、パターンマッチングをサポートしています。 一般的な用途の 1 つは、enum のバリアントに対してマッチングすることです。 たとえば、OS はプロセスの状態に応じて異なる関数を実行できます。

fn manage_process(curr_state: State) {
    match curr_state {
        State::Running => stop_and_schedule_another_process(),
        State::Stopped => assign_to_available_cpu_core(),
        State::Sleeping => check_if_data_ready_and_wake_if_so(),
    }
}

match の括弧内の各行はアームと呼ばれます。 パターンは矢印演算子（=>）の左側にあり、そのパターンにマッチした場合に実行されるコードは右側にあります。 制御フローを扱う次のセクションで、パターンマッチングについてさらに詳しく説明します。

Rust の enum が C、C++、その他多くの言語の enum と異なる点は、さまざまな型の追加データをカプセル化できることです。 この能力により、Rust の enum は関数型言語における「直和型」（これは「代数的データ型」の特定の一種です）に似たものになります。 実際には、これは各バリアントに任意のデータを格納できる柔軟性があることを意味します。 そのデータは、さらに別の enum であることさえあります。

より細かなプロセス状態表現に対する設計要件があったとしましょう。 具体的には、OS が次のことを行う必要があるとします。

• 2 種類の停止要求を追跡する: プロセスが無視できるものと、無視できないもの。

• sleeping 状態のプロセスについて開始タイムスタンプを記録し、後で sleeping 状態のプロセスがどれだけ長く非アクティブだったかを計算する。

State enum を、新しい要件を反映した DetailedState に置き換えることができます。

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
pub enum StopKind {
    Mandatory, // Linux SIGSTOP
    Ignorable, // Linux SIGTSTP
}

pub enum DetailedState {
    Running,
    Stopped { reason: StopKind },
    Sleeping { start_time: u64 },
}

Stopped バリアントには別の enum（StopKind - その上の #[derive(... は今は無視してください）が含まれるようになり、Sleeping バリアントには u64 タイムスタンプ（UNIX のエポック表現に似たもの³）が含まれるようになったことに注目してください。 それでも、Running バリアントは空のままです。

バリアント内にカプセル化されるデータ型は自由に選択でき、マッチング時には内部の型を「取り出す」こともできます。 以下のスニペットは、最初のアームが Stopped バリアントの内部データをチェックするテストです。 2 番目のアームはワイルドカード（_）を使用して、このテストが他のどのバリアントにもマッチしないことを表明しています（state がハードコードされているためです）。

#[test]
fn test_detailed_stop_match() {
    let state = DetailedState::Stopped {
        reason: StopKind::Mandatory,
    };
    match state {
        DetailedState::Stopped { reason } => {
            assert_eq!(reason, StopKind::Mandatory);
        }
        _ => unreachable!(), // 到達した場合、実行時にパニックする
    }
}

厄介な細部が 1 つあります。enum のメモリ上のサイズは、最大のバリアントによって決まります。 Running バリアントのインスタンスは、後者の方がより多くの情報を保持しているにもかかわらず、Sleeping バリアントのインスタンスと同じサイズです。 メモリレイアウトは頻繁に考える必要があるものではありませんが、注目に値します。 私たちは高機能な直和型を使っているかもしれませんが、それでも低レベルのコードを書いているのです。

構造体

構造体、具体的には以下のような名前付きフィールドを持つ struct は、ほとんどの Rust プログラムでデータを表現する主要な方法です。 Rust の struct は、Python のクラスや Java のオブジェクトと同じ目的を果たします。つまり、データと、そのデータを操作する関数をまとめる方法です⁴。

OS カーネルの主な責務の 1 つはタスクスケジューリング、つまりどのプロセス（またはそのスレッド）をどの CPU コア上でどれだけの時間実行すべきかを決定することです。 多くのプログラムは複数のプロセスで構成されており、親プロセスは 1 つ以上の子プロセスを作成できます。

OS を実装しているとしたら、プロセスに関連するデータを struct にまとめたいと思うでしょう。 単純化した例⁵は、次のようになります。

pub struct Proc {
    pid: u32,           // プロセス ID（符号なし整数）
    state: State,       // 現在の状態（enum）
    children: Vec<u32>, // 子 ID（動的リスト）
}

マルチプロセスプログラムはどのように動作するのか？

あるプログラム（親プロセス）は、2つ目の補助プログラム（子プロセス）を起動（たとえば「spawn」）できます。 補助プログラムが独立した作業を行っている場合、最新のマルチコアシステムでは、両方を同時に実行できます。 親はあるコア上で実行され、子は別のコア上で実行されます。

これが、Webブラウザーをより高速で応答性が高いように感じさせる要因です。 デフォルトでは、Chromium は接続先のWebサイトごとに1つのプロセスを実行します⁶。

Proc 構造体は、問題領域における概念（OSが管理するプロセスという考え方）を型付きデータとして表します。 データを扱いやすくするために、前の章で Rc4 構造体に対して行ったのと同じように、メソッド（self パラメーターを持つ）と関連関数（self パラメーターを持たない）を追加することになるでしょう。 どちらの種類の関数も、構造体の impl ブロック内で定義する必要があります。 例:

impl Proc {
    /// 関連関数（コンストラクター）
    pub fn new(pid: u32) -> Self {
        Proc {
            pid,
            state: State::Stopped,
            children: Vec::new()
        }
    }

    /// メソッド（self を受け取る。この場合は可変セッター）
    pub fn set_state(&mut self, new_state: State) {
        self.state = new_state;
    }

    // ...ここにさらにメソッド/関数
}

名前付きフィールド（pid、state、children）はデフォルトで非公開であることに注意してください。 それらには、その構造体が定義されているモジュール内のコードからしかアクセスできません。 モジュールは関連するコードをまとめる方法であり、Rust における名前空間のようなものだと考えてください。

このコードが Proc をインポートした別のモジュールにある場合、非公開フィールド state に代入できないため、コンパイルされません。

use my_os_module::Proc;

let mut my_proc = Proc::new(0);
my_proc.state = State::Running;

そのためセッターメソッドを定義しました。以下は動作します。

use my_os_module::Proc;

let mut my_proc = Proc::new(0);
my_proc.set_state(State::Running);

このようなデータのカプセル化⁷は、公開APIにおけるベストプラクティスと見なされています。 ただし必須ではなく、常に適切であるとも限りません。 外部コードから state を書き込み可能にしたい場合（たとえば my_proc.state = State::Running; が動作するようにしたい場合）は、宣言時に pub 可視性指定子を使用できます。

pub struct Proc {
    pid: u32,           // プロセスID（符号なし整数）
    pub state: State,   // 現在の状態（列挙型）
    children: Vec<u32>, // 子ID（動的リスト）
}

モジュールと可視性については、この章の後半で説明します。

Rust が保守的なアプローチを取っていることに注目してください。外部への可視性、可変性、安全でない操作はいずれも、明示的なオプトインを必要とします。 これは、大規模なプログラムにおける潜在的なエラー要因を減らすのに役立つ、意識的な設計上の選択です。

ジェネリクス

私たちはすでにジェネリックなライブラリを使っています。標準ライブラリの Vec です。 これは Vec<T> として定義されており、T はジェネリック型です。 そのため、格納したい要素の型ごとに異なるライブラリAPIを使う必要なく、符号なし整数のベクター（Vec<usize>）と文字列のベクター（Vec<String>）の両方を持つことができます。

自分のために単一の趣味OSを書いているのではなく、実際には再利用可能なスケジューリングライブラリ、つまりOSを書く誰もが利用できる可能性のあるコードを書いていると想像してください。 ここでジェネリクスが登場します。 構造体や関数の特定のインスタンスを作成する代わりに、あなたのコードの利用者が型を差し込めるテンプレートを定義できます。 将来書かれる外部コードで定義されたカスタム型も含めることができます！

あなたの利用者の中には、同時に100個を超えるプロセスが実行されることが決してない、小さな組み込みデバイス向けのOSを書いている人がいるかもしれません。 彼らは pid を表すために u32 ではなく u8 を使うことで、貴重なメモリを節約する必要があります。 しかし、単に pid の型を u8 に変更することはできません。他の利用者は数千のプロセスを表す必要があるからです。 Proc の定義と実装をジェネリックに更新すれば、両方のグループに対応できます。

pub struct Proc<T> {
    pid: T,             // プロセスID（ジェネリック）
    pub state: State,   // 現在の状態（列挙型）
    children: Vec<T>,   // 子ID（動的リスト、ジェネリック）
}

impl<T> Proc<T> {
    // 関連関数（コンストラクター）
    pub fn new(pid: T) -> Self {
        Proc {
            pid,
            state: State::Stopped,
            children: Vec::new()
        }
    }

    // ...ここにさらにメソッド/関数
}

リソース制約のある利用者は let mut my_proc: Proc<u8> = Proc::new(0); を指定でき、他の利用者は let mut my_proc: Proc<u32> = Proc::new(0); を使えます。 私たちのコードは、どちらにも対応できるだけの柔軟性を持つようになります。

最終的なバイナリ内でジェネリクスはどのように動作するのか？

Rust コンパイラーは、単相化によってジェネリクスを実装します。 各呼び出し箇所で使用される具体的な型（u8 など）ごとに、コンパイラーは出力バイナリ内に特殊化されたコードを生成します。 そのため、ジェネリクスには実行時コストがありません。各一意な T の「テンプレート」が、最終的な実行可能ファイル内に1つの「スタンプ」（一意なコード）を作成します。

ジェネリクスは Rust の中核的な機能であり、頻繁に目にすることになります。 トレイトと組み合わせることで、再利用可能で保守しやすいソフトウェアコンポーネントの作成が可能になります。

トレイト

ここまで説明してきた構成要素は、主流の言語からそれほど大きく外れたものではありません。 Rust の列挙型とパターンマッチングは、すでに馴染みのある言語機能の拡張のように感じられるでしょう。 多くの読者にとって、Rust がかなり違って感じられ始めるのはトレイトからです。

以前、Rust の構造体は Python のクラスや Java のオブジェクトと同じ役割を果たすと述べました。 しかし、これら2つの言語とは異なり、Rust は継承をサポートしていません。 クラス階層は存在せず、構造体が親からフィールドやメソッドを継承することはできません。

その代わり、共有される振る舞いは合成によって、つまりトレイトを通じて定義されます。 このアプローチは、オブジェクト指向言語においてさえベストプラクティスだと考える人もいます⁸。

コードレベルの仕組みとしては、トレイトはオブジェクト指向言語における「抽象基底クラス」に似ています。 つまり、トレイトを実装する任意の型がサポートしなければならないインターフェース（APIの集合）を定義するということです。

型は1つ以上のトレイトを実装でき、そうすることで、そのトレイトが適切な任意のコンテキストでその型を使用できるようになります。

そもそも継承とは何でしょうか？

継承は「サブタイプ多相」の一種で、2つの型の限定的な置換を可能にします。

たとえば、Vehicle クラスに accelerate(int speed_mph) メソッドがあり、Car と Plane の両方のサブクラスがそれを継承しているとします。 Vehicle の派生型の配列を処理し、Car と Plane の両方で accelerate を呼び出すコードを書きたいとします。 継承がその目標を達成する方法は2つあり、ほとんどの言語はその両方を提供しています。

• インターフェイス継承: Car と Plane は Vehicle の公開メソッドインターフェイスを共有しますが、実際の accelerate の実装はそれぞれ独自にオーバーライドします。ここで、Vehicle は「抽象基底クラス」として機能します。Rust のトレイトはこのベストプラクティスを体現しています。

• 実装継承: Car と Plane は Vehicle の汎用的な accelerate メソッドのデータと実装を共有します。このパターンは実際のプログラムで広く使われていますが、基底クラスと派生クラスが密結合になるため、コードの保守や拡張が難しくなる可能性があります。

では、トレイトはどのような振る舞いを指定できるのでしょうか？ また、それらをどのように利用するのでしょうか？ それを確認するために、Proc 構造体に2つのトレイトを追加してみましょう。

トレイト Debug を導出する

構造体のテキスト表現を出力できることは、デバッグに役立ちます。 実際、これは非常によくあるニーズであるため、Rust はこの目的専用のデフォルトのフォーマット指定子 {:?} を提供しています。 これを使って、元の非ジェネリックな Proc 構造体を出力してみましょう。

pub enum State {
    Running,
    Stopped,
    Sleeping,
}

pub struct Proc {
    pid: u32,           // プロセスID（符号なし整数）
    state: State,       // 現在の状態（列挙型）
    children: Vec<u32>, // 子ID（動的リスト）
}

fn main() {
    let my_proc = Proc {
        pid: 1,
        state: State::Stopped,
        children: Vec::new(),
    };

    println!("{:?}", my_proc);
}

次のエラーが発生します（いくつかの行は省略しています）。

error[E0277]: `Proc` doesn't implement `Debug`
  --> src/main.rs:20:22
   |
20 |     println!("{:?}", my_proc);
   |                      ^^^^^^^ `Proc` cannot be formatted using `{:?}`
   |
   = help: the trait `Debug` is not implemented for `Proc`
   = note: add `#[derive(Debug)]` to `Proc` or manually `impl Debug for Proc`

{:?} を使いたい場合、コンパイラは Proc が Debug トレイト⁹を実装していることを必要とします。 このトレイトは、実装者をコンソールへどのように出力すべきかを定義するもので、一般的かつ望ましい振る舞いです。 この時点で選択肢は2つあります。

1. std::fmt::Debug のドキュメント⁹を確認し、それが要求するインターフェイスを理解して（この場合は関数1つだけです）、impl Debug for Proc { ... } ブロック内でそのインターフェイスを実装する。

2. derive マクロ #[derive(Debug)] を使って、トレイトを自動的に導出してみる。

後者の選択肢のほうが簡単で、ドキュメント⁹でも推奨されている方法です。

Rust のドキュメントに慣れる

まだ行っていない場合は、ここで少し時間を取って Debug トレイトのドキュメント⁹を確認してください。 関数シグネチャ全体はまだ理解できないかもしれませんが、それでも大まかなところはつかめるはずです。

ライブラリのドキュメントを理解することは、どんな開発者にとっても重要なスキルですが、Rust プログラミングでは特に役立ちます。 Rust には組み込みのファーストパーティ製ドキュメントジェネレーターがあるため、人気のあるライブラリは十分に文書化されている傾向があります（これについては後ほど取り上げます！）。

提案された更新を行ってみましょう。

#[derive(Debug)]
pub struct Proc {
    pid: u32,           // プロセスID（符号なし整数）
    state: State,       // 現在の状態（列挙型）
    children: Vec<u32>, // 子ID（動的リスト）
}

今度は新しいエラーが発生します（別名、プログラマーにとっての「進捗」）。

error[E0277]: `State` doesn't implement `Debug`
  --> src/main.rs:10:5
   |
7  | #[derive(Debug)]
   |          ----- in this derive macro expansion
...
10 |     state: State,       // 現在の状態（列挙型）
   |     ^^^^^^^^^^^^ `State` cannot be formatted using `{:?}`
   |
   = help: the trait `Debug` is not implemented for `State`
   = note: add `#[derive(Debug)]` to `State` or manually `impl Debug for State`

まあ、完全に新しいわけではありません。これは先ほどと同じエラーですが、今回は Proc の state フィールドに対するものです。 合成によって振る舞いを定義するという考え方を覚えていますか？

構造体の個々のフィールドすべてが Debug トレイトを実装しているなら、構造体全体に対してそれを導出するのは簡単です。その振る舞いは、各フィールドの個別の振る舞いを合成したものにすぎません。 すべてを厳格な階層に押し込む必要なく、強力な抽象化を構築し、既存のコードを再利用できます。

この2つ目のエラーによると、残っている唯一の障害は State 型が Debug を実装していないことです。 それを修正しましょう。

#[derive(Debug)]
pub enum State {
    Running,
    Stopped,
    Sleeping,
}

これでプログラムはコンパイルされ、実行できるようになります。 期待どおりの出力が得られます。

Proc { pid: 1, state: Stopped, children: [] }

Debug 出力のクイックヒント

システムコードのデバッグでは、構造体を16進数値で、かつ1フィールドにつき1行で出力すると便利なことがよくあります。 main の最後の行を println!("{:#x?}", my_proc); に更新すると、プログラムは次のように出力します。

Proc {
  pid: 0x1,
  state: Stopped,
  children: [],
}

トレイト Ord を実装する

トレイトは常に自動導出できるとは限りません。 たとえば、Aead トレイト¹⁰を考えてみましょう。 これはサードパーティライブラリで定義されており、Associated Data 付き認証暗号（Authenticated Encryption with Associated Data、AEAD）暗号のための［非公式な］インターフェイスを指定しています。 前の章で見たように、これはメッセージの機密性と完全性の両方を提供する暗号アルゴリズムのファミリーです¹¹。

Rust のトレイトシステムは強力ですが、derive マクロが暗号コードを合成してくれるわけではありません。 トレイトは単なるインターフェイスであり、背後にあるロジックは自分で実装しなければならないことがよくあります。

さらに、トレイトが導出可能であっても、デフォルトの振る舞いが望むものとは限りません。 たとえば、OS がプロセス構造体のソート済みリストを維持する必要があるとします。 ソートには「順序」の概念が必要です。 数学者が「全順序」¹²と呼ぶものです。 根底にある考え方は、論理比較演算子（==、>、<= など）を使ってソートしたいということであり、これらの比較を曖昧さなく行える必要があります。

Rust の標準ライブラリには、順序付け専用のトレイト Ord¹³ が含まれています。 これを実装した型は、同じ型の項目と比較可能になり、そのコレクションはソート可能になります。 多くの文脈で、これはサポートすると非常に有用な振る舞いです。

Proc に対して Ord を導出できるでしょうか？ はい、できます。 ただし、ドキュメント¹³によると、Ord は他のトレイト、すなわち PartialEq、Eq、PartialOrd に依存しています。 なぜなら、トレイト自体も合成によって定義できるからです！

これら4つの順序関連トレイトの違いについて細かくこだわるのはやめましょう。 代わりに、それらを導出すると何が起こるかを考えてみましょう。

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
pub enum State {
    Running,
    Stopped,
    Sleeping,
}

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
pub struct Proc {
    pid: u32,           // プロセスID（符号なし整数）
    state: State,       // 現在の状態（enum）
    children: Vec<u32>, // 子ID（動的リスト）
}

fn main() {
    let my_proc_stopped = Proc {
        pid: 1,
        state: State::Stopped,
        children: Vec::new(),
    };

    let my_proc_sleeping = Proc {
        pid: 3,
        state: State::Sleeping,
        children: Vec::new(),
    };

    let my_proc_running = Proc {
        pid: 2,
        state: State::Running,
        children: Vec::new(),
    };

    let mut proc_queue = vec![
        my_proc_stopped,
        my_proc_sleeping,
        my_proc_running,
    ];

    proc_queue.sort();

    println!("{:#?}", proc_queue);
}

上記では、3つのプロセスからなる Vec（proc_queue）を作成し、それをソートしています。 なぜ proc_queue.sort() を呼び出せるのでしょうか？ Vec<T> のドキュメント¹⁴にある sort の関数シグネチャを考えてみましょう。

pub fn sort(&mut self)
where
    T: Ord,
{
    // ...ここにコード
}

where T: Ord は トレイト境界 です。 これは、その関数が機能するために T がどのような振る舞いをサポートする必要があるかを規定します。 つまり、sort は任意の Vec<T> で利用できますが、T が Ord を実装する型である場合に限られます。 上記のコードが動作する理由は次のとおりです。

1. 型推論により let mut proc_queue: Vec<Proc> = ... が補完されました。

2. Proc 構造体が Ord トレイトを導出しました。

トレイト境界は、コードの再利用とライブラリの組み合わせやすさに大きな影響を及ぼします。 Vec はジェネリックなコンテナであり（まだ発明されていない型に対しても動作します）、特定の振る舞いをサポートする要素に対して追加の機能を提供します（たとえば、順序付け可能な型をソートするなど）。

しかし、Vec は公式の標準ライブラリだけが実装できるような一回限りの特別なものではありません。 任意の Rust 開発者も同様に、ジェネリクスとトレイトを使って、同じくらい有用なデータ構造を実装できます。 本書では、別の標準ライブラリコレクションと API 互換の代替実装を書きます。

トレイト境界により、異なるコンポーネントを迅速かつ自信を持って組み合わせ、大規模で調和の取れたシステムを構築できます。 これは強力な高レベルの構成要素です。

Rust 構文を読む

Rust を読むことに慣れるには時間がかかります。構文が複雑だからです。 where キーワードは実際には可読性のための便宜的なもので、上記の sort シグネチャは次と同等です。

pub fn sort<T: Ord>(&mut self) {
   // ...ここにコード
}

しかし、T はどこから来たのでしょうか？ どちらの sort のバリエーションも単独の関数ではなく、どちらも Vec<T> の impl ブロック内に存在します。 簡潔にするためその詳細は省略しましたが、これは重要な点です。

impl<T> Vec<T> {
  pub fn sort<T: Ord>(&mut self) {
      // ...ここにコード
  }

  // ...ここに他の関数
}

したがって、トレイト境界のおかげで、sort() の呼び出しは機能します。 しかし、それはうまく機能しているのでしょうか？ これは議論の余地があります。出力を見ると、pid でソートされていることがわかります。

[
    Proc {
        pid: 1,
        state: Stopped,
        children: [],
    },
    Proc {
        pid: 2,
        state: Running,
        children: [],
    },
    Proc {
        pid: 3,
        state: Sleeping,
        children: [],
    },
]

導出された複合的な振る舞いは、構造体の1番目のフィールド（pid）でソートしようとします。 値がたまたま等しい場合は、2番目のフィールド（state。これも Ord を導出しています）でソートします。 それらの値もたまたま等しい場合は、3番目のフィールド（children）でソートします。以降も同様です。

これはコンパイルされて実行されましたが、私たちが望む振る舞いとは少し異なります。 私たちの OS がこのプロセス一覧をスケジューリングキューとして使い、次にどのプロセスを実行するかを決めると想像してください。 その場合、pid 優先ではなく、何らかの優先度の概念に基づいてソートする必要があります。

現実世界のスケジューリングアルゴリズムは複雑になり得ます¹⁵。 簡単にするため、ここでは現在の State のみに基づく3つの優先度があると仮定します。 Sleeping のプロセスは実行対象として最も高い優先度を持つべきで、その次に Stopped のプロセスが続きます。 Running のプロセスは、定義上すでに実行中であり、最も低い優先度です。 それらはリストの末尾に置きたいとします。 いよいよ Ord を難しい方法で実装する時です！

まず、State enum が内部でどのように機能するかをもう少し理解する必要があります。 メモリ上では、各バリアントは 判別子、つまり整数値で始まります。 これはそのバリアントに固有のタグのようなものです。

もし2つの pid が等しかった場合、state を見てソートの同順位を解決する必要がありました。 したがって、この判別子の整数値がソートに関わることになります。 State に導出された Ord はそのまま残しつつ、デフォルト値を上書きして、選択した優先度を反映しましょう。

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)]
pub enum State {
    Running = 3,    // デフォルトでは0
    Stopped = 2,    // デフォルトでは1
    Sleeping = 1,   // デフォルトでは2
}

Proc 構造体については、各ドキュメントに従って、Ord¹⁶、PartialOrd¹⁷、PartialEq¹⁸ トレイトで必要とされる実際の関数を実装します。 Eq¹⁹ は引き続き導出できます。これは PartialEq によって暗黙に示され、独自のメソッドを持たないためです（これは他のトレイトには一般化できない技術的な事情です）。

use std::cmp::Ordering;

#[derive(Debug, Eq)]
pub struct Proc {
    pid: u32,           // プロセスID（符号なし整数）
    state: State,       // 現在の状態（enum）
    children: Vec<u32>, // 子ID（動的リスト）
}

impl Ord for Proc {
    fn cmp(&self, other: &Self) -> Ordering {
        self.state.cmp(&other.state)
    }
}

impl PartialOrd for Proc {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Proc {
    fn eq(&self, other: &Self) -> bool {
        self.state == other.state
    }
}

上記のコードの詳細そのものよりも、その含意の方が重要です。これで言語は非常に根本的なレベルで、Proc 構造体の順序付けを行う際に state フィールドだけを考慮するようになります。 いくつかの特定のトレイトを実装することで、ソートや比較のようなさまざまなコンテキストにおいて、その構造体がどのように振る舞うかを定めたのです。

この新しい Ord の実装と、それが依存するトレイトにより、println!("{:#?}", proc_queue); は、私たちが望む state 優先の順序を出力するようになります。

[
    Proc {
        pid: 3,
        state: Sleeping,
        children: [],
    },
    Proc {
        pid: 1,
        state: Stopped,
        children: [],
    },
    Proc {
        pid: 2,
        state: Running,
        children: [],
    },
]

注意してください。トレイトは強力です！

トレイトを手動で実装することで、ソートのために Proc 構造体をどのように順序付けるべきかだけでなく、2つの Proc 構造体が等しいとは何を意味するのかも変更しました！

これで、同じ state を持つ任意の2つの構造体は、たとえ異なる pid と children を持っていても、== 演算子に関する限り論理的に同等であると見なされます。

トレイトを手動で実装するときは常に、その実装がもたらすすべての影響が、あなたのプログラムにとって本当に適切であることを確認することが重要です。

この場合、トレイトの実装は実際には過剰です（重要な概念を説明するためだけに行いました）。 代わりに、enum の判別子を更新した後で、Vec の sort_by_key 関数²⁰を使うこともできました。

proc_queue.sort_by_key(|p| p.state);

要点

Rust が高レベルの構成要素を表現するために備えている機能には、enum、構造体、ジェネリクス、トレイトがあります。 振り返ると、次のとおりです。

• enum は、取り得る値の有限集合を表現するのに役立ちますが、追加のデータを保持することもできます。

• 構造体は、関連するデータと、それに対して動作する関数をまとめる方法であり、他の言語におけるクラスやオブジェクトに似ています。

• ジェネリクスはコードの再利用を可能にします。関数や構造は一度だけ書けばよく、それでいて異なる型をサポートできます。コード重複を避けるのに便利というだけでなく、ライブラリ設計にとっては本当に強力な機能です。

• トレイトは、コンポジションを通じて共有される振る舞いを可能にします。トレイトは特定のインターフェイスを定義し、derive したり実装したりでき、ジェネリックパラメーターに境界として指定されたときに特に有用になります。

所有権に踏み込む前に、より単純なトピックである制御フローについて話して、少し一息つきましょう。

ドメイン固有の不変条件を型システムに直接エンコードできるでしょうか？

限定的ながらも強力な形で、できます。 ときには、重要なドメイン固有の振る舞いを状態機械としてモデル化できます。 それは一連の状態を遷移する構造であり、特定の操作は特定の状態でのみ実行できます。 そして、合法な遷移も特定のものだけです。

typestate パターンは、構造体が取り得る実行時状態をコンパイル時にエンコードする方法です。 これにより、状態に関連するエラー（静的な正しさ）と、一部の実行時チェックの必要性（性能）の両方を排除できます。前者の利点は、次のものに適しています。

[RR、Directive 4.13] リソースに対して動作する関数は、正しい順序で呼び出されなければならない²¹

typestate パターンの Rust における実装については、将来の付録セクションで扱います。

1. The Rust Reference: Influences. The Rust Team (2021). ↩

2. Tock. Tock OS (2022年参照)。オペレーティングシステムは、おそらくシステムソフトウェアの典型的な例であり、Rust がよく適している領域です。Rust で書かれた OS はいくつかあり、Tock はその1つです。 ↩

3. The Current Epoch Unix Timestamp. Dan’s Tools (2022年参照)。 ↩

4. Rust では、enum に対してメソッドや関連関数を定義することもできます。構造体に限定されているわけではありません。しかし、構造体のほうがより一般的に使われており、多くのプログラミング問題では、複数の異なるバリアントを持つデータのグループを表現する必要はありません。 ↩

5. 実際の OS ははるかに複雑なタスク構造を持っており、このセクションの例は大幅に簡略化されています。興味があれば、Linux の task_struct のソースコードをこちらで確認できます。 ↩

6. Process Models. The Chromium Project (2022年参照)。 ↩

7. Data encapsulation. Wikipedia (2022年参照)。 ↩

8. Composition over inheritance. Wikipedia (2022年参照)。 ↩

9. トレイト std::fmt::Debug. The Rust Team (2022年参照)。 ↩ ↩2 ↩3 ↩4

10. トレイト aead::Aead. RustCrypto organization (2022年参照)。 ↩

11. Authenticated encryption. Wikipedia (2022年参照)。 ↩

12. 全順序 Wikipedia (2022年参照)。 ↩

13. トレイト std::cmp::Ord. The Rust Team (2022年参照)。 ↩ ↩2

14. sort. The Rust Team (2022年参照)。 ↩

15. Scheduling Algorithms. OSDev Wiki (2021)。 ↩

16. トレイト std::cmp::Ord. The Rust Team (2022年参照)。 ↩

17. トレイト std::cmp::PartialOrd. The Rust Team (2022年参照)。 ↩

18. トレイト std::cmp::PartialEq. The Rust Team (2022年参照)。 ↩

19. トレイト std::cmp::Eq. The Rust Team (2022年参照)。 ↩

20. sort_by_key. The Rust Team (2022年参照)。 ↩

21. MISRA C: 2012 Guidelines for the use of the C language in critical systems (3rd edition). MISRA (2019). ↩

Rust: 制御フロー（3/6）

ほとんど¹すべての有用なプログラムは、条件に基づいて何らかの判断を行うか、何らかのロジックを複数回実行します。 したがって、すべての命令型プログラミング言語は、制御フローを決定するための何らかの仕組みを提供します。つまり、個々の文が実行される順序を決める仕組みです。

言語は、制御フローを表現するために同じような少数の構文に落ち着く傾向があります。 Rust も例外ではありません。 Rust のパターンマッチングは、あなたがどの言語から来たかによっては新しいものかもしれませんが、条件文やループは馴染みのあるものに感じられるはずです。

条件文

if キーワードと else キーワードは、おおむね期待どおりに動作します。

fn conditional_print(num: usize) {
    if num > 10 {
        println!("{} is greater than 10.", num);
    } else if num % 2 == 0 {
        println!("{} is even.", num);
    } else {
        println!("{} is odd.", num);
    }
}

fn main() {
    conditional_print(11);
    conditional_print(4);
    conditional_print(5);
}

上記の出力は次のとおりです。

11 is greater than 10.
4 is even.
5 is odd.

Rust が異なる点は、if キーワードの後の条件が bool 型に評価されなければならないことです。 暗黙的なキャストは許可されません。 この厳格さは、別の MISRA ルールに従う助けになります。

[AR, Rule 14.4] if 式は boolean 型に評価されなければならない²

他の多くの言語では、条件文に対して厳密な型付けを強制していません。

• Python では、条件が None 値に評価されると、それは暗黙的に false にキャストされます。

• 同様に C では、ゼロの整数は暗黙的に false にキャストされます（非ゼロは true にキャストされます）。

これは、Rust で条件を表現する能力を妨げるものではありません。 x == None や y != 0 は、依然として明示的に書き下すことができます。 しかし、潜在的なエラーの原因を 1 つ取り除くことにはなります。

While ループ

while キーワードを使うと、boolean 条件が成り立っている限りループを実行し続けることができます。 以下は 10 から 1 までのカウントダウンを出力します。

#![allow(unused)]
fn main() {
let mut countdown = 10;

while countdown > 0 {
    println!("{}...", countdown);
    countdown -= 1;
}
}

Rust は「do while」ループを直接サポートしていませんが、同じロジックは loop キーワードと break キーワードを使って実装できます。 同等のカウントダウンは次のように実装できます。

#![allow(unused)]
fn main() {
let mut countdown = 10;

loop {
    println!("{}...", countdown);
    countdown -= 1;
    if countdown == 0 {
        break;
    }
}
}

For ループ

for キーワードを使うと、任意のイテラブルをループできます。 範囲を例に取りましょう。 以下は 0 から 9 までの数値を出力します。

#![allow(unused)]
fn main() {
for i in 0..10 {
    println!("{}", i);
}
}

ループ内でコレクションの要素にアクセスしたい場合はどうでしょうか。 表面的には、私たちの for 構文は「そのまま動く」ように見えます。

#![allow(unused)]
fn main() {
use std::collections::{HashSet, BTreeSet};

// リスト
let list = vec![3, 2, 1];

println!("Iterating over vector:");

for item in list {
    println!("list item: {}", item);
}

// 順序付き集合
let mut o_set = BTreeSet::new();
o_set.insert(3);
o_set.insert(2);
o_set.insert(1);

println!("\nIterating over ordered set:");

for elem in o_set {
    println!("set element: {}", elem);
}

// ハッシュ集合
let mut h_set = HashSet::new();
h_set.insert(3);
h_set.insert(2);
h_set.insert(1);

println!("\nIterating over hash set:");

for elem in h_set {
    println!("set element: {}", elem);
}
}

しかし、上記の出力を考えてみましょう。

Iterating over vector:
list item: 3
list item: 2
list item: 1

Iterating over ordered set:
set element: 1
set element: 2
set element: 3

Iterating over hash set:
set element: 2
set element: 3
set element: 1

各コレクションには、要素にアクセスするための独自の戦略があります。

• Vec（リスト）は、値を挿入された順序で返します。
• BTreeSet（順序付き集合）は、互いに相対的なソート順で値を返します。
• HashSet（ハッシュ集合）には、ソート順であれ挿入順であれ、順序という概念がありません。

内部では、各コレクションが独自のイテレーターを実装しています。 それぞれ独自のロジックを持っていますが、共通のインターフェイスである Iterator トレイトを共有しています³。 for ループはこのインターフェイスを活用して、基盤となるデータ構造の走査を行います。

イテレーターは慣用的な Rust の重要な一部であり、独自のイテレーターを実装することに丸ごと 1 章を割きます。 今は、イテレーターが便利さの世界を可能にすることを知っておいてください。 たとえば列挙です。

#![allow(unused)]
fn main() {
let list = vec![3, 2, 1];

for (i, item) in list.iter().enumerate() {
    println!("list item {}: {}", i, item);
}

// 出力:
//
// list item 0: 3
// list item 1: 2
// list item 2: 1
}

そして関数型の変換です。

#![allow(unused)]
fn main() {
let list = vec![3, 2, 1];

let triple_list: Vec<_> = list.iter().map(|x| x * 3).collect();

for item in triple_list {
    println!("triple_list item: {}", item);
}

// 出力:
// triple_list item: 9
// triple_list item: 6
// triple_list item: 3
}

イテレーターは、範囲外（Out-Of-Bounds、OOB）インデックス指定のような一般的なエラーも防ぎます。 これは次に準拠する助けになります。

[AR, Rule 14.2] for ループは整形式でなければならない²

パターンマッチング

最も単純な使い方では、パターンマッチングは C の switch 文に似ています。有限集合から 1 つのアクションを選択します。

前のセクションでは、enum バリアントに対する match を見ました。 これは、ドメイン固有のコンテキストに基づいて異なるアクションを取る便利な方法になり得ます。 復習すると、次のとおりです。

#[derive(Debug)]
pub enum State {
    Running,
    Stopped,
    Sleeping,
}

fn do_something_based_on_state(curr_state: State, pid: u32) {
    match curr_state {
        State::Running => stop_running_process(pid),
        State::Stopped => restart_stopped_process(pid),
        State::Sleeping => wake_sleeping_process(pid),
    }
}

C の switch とは異なり、パターンマッチングでは式のリストと、それぞれに対応するアクションを指定できます。 式を使うと、比較的複雑な条件を簡潔にエンコードできます。 例:

#![allow(unused)]
fn main() {
let x = 10;

match x {
    1 | 2 | 3 => println!("number is 1 or 2 or 3"),
    4..=10 => println!("number is between 4 and 10 inclusive"),
    x if x * x < 250 => println!("number squared is less than 250"),
    _ => println!("number didn't meet any previous condition!"),
}
}

• 1つ目のmatchアーム（1 | 2 | 3 => ...）は、3つのリテラル値を指定しています。マッチ対象の変数 x がその3つのいずれかと等しい場合にトリガーされます。

• 2つ目のアームは、4から10までを含む範囲を指定しています。x がその範囲内のいずれかの値である場合にトリガーされます。

• 3つ目のアームはガード式を使用します。x にそれ自身を掛けた値が250未満の場合にトリガーされます。

• 4つ目で最後のアームはデフォルトケースです。ワイルドカード _ を使ってあらゆるものにマッチします。前のケースがどれもトリガーされなかった場合にのみトリガーされます。

入力は複数のアームにマッチすることはできず、適合する最初のパターンにのみマッチすることに注意してください。 したがって、順序は重要です。

Rustでは、マッチが網羅的であることも要求されます。つまり、プログラマーは考えられるすべてのケースを処理しなければなりません。 最初の例で State バリアントを網羅的にマッチするのは簡単でした。Running、Stopped、Sleeping の3つしかないためです。

2つ目の例では、let x = 10; は x の型を指定していませんでした。 そのため、コンパイラはデフォルトで i32 と推論しました。 32ビット符号なし整数の考えられるすべての値を網羅的にマッチするのは面倒です。その代わりに、各パターンは考えられる値のサブセットをカバーしています。

4つ目のパターンであるワイルドカードのデフォルトは、何も見逃さないようにするために必要です。 その行が省かれていた場合、たとえば x が 16 であるケースを処理できません。

網羅性の要件により、私たちが書くどの match も考えられるあらゆる入力を適切に処理することが保証されます。これは、別のMISRAルールの精神に合致します。

[AR, Rule 16.4] switch文にはデフォルトケースがなければならない²

このルールはCの switch 文に特化したものですが、堅牢なマッチングという考え方は引き継がれます。適切なアクションを取らずに、switch/match をうっかり「フォールスルー」してしまうことは決して避けるべきです。

簡潔なパターンマッチング

Rustは、特定のパターンが適合したときにトリガーされる単一の条件付きアクションへとパターンマッチングを簡潔にまとめる構文を提供しています（残りは無視します）。 Rustコードで if let や while let を見かけた場合、それは単一の match アームへ「掘り下げる」ための省略記法です。

この構文は最初のうちは分かりにくいことがあるため、本書の後半で、より大きなプログラムの文脈の中で徐々に紹介していきます。 予告として、次のコードを考えてみましょう（前に使った State enumを使用していると仮定します）。

let curr_state = State::Running;

match curr_state {
    State::Running => println!("Process is running!"),
    State::Stopped => {},   // 何もしない
    State::Sleeping => {},  // 何もしない
};

これは、次の省略記法と同等です。

let curr_state = State::Running;

if let State::Running = curr_state {
    println!("Process is running!");
}

Running 状態の場合にだけメッセージを出力していますが、異なるケースを網羅的に match する必要はないことに注目してください。 その代わりに、if let によって特定の enum バリアントに対してのみ条件付きアクションを実行できます。

前述のMISRAルールに照らすと、他のケースを無視することで堅牢性を失っているのでしょうか？ 少し意外かもしれませんが、必ずしもそうではありません。

• if let は他の if 文と同様に、特定の条件が真である場合にのみ本体が実行されます。設計上、網羅的であることを意図していません。if は1つのケースにだけ「関心」を持ちます。そしてそれは読み手にとって明らかです。

• match は複数のパターンをサポートし、入力がどれをトリガーするかを知りません。設計上、それらすべてを処理する責任があります。そのため、コンパイラが網羅性を強制します。そうでなければ、読み手が見落とす可能性があります。

match と if let のどちらが適切かを判断することは、より広いプログラムの文脈に依存します。

まとめ

Rustの制御フロー構文は、他のプログラミング言語と大きく異なるわけではありません。 while ループは期待どおりに動作し、for ループはイテレーターに支えられており、「do while」は別の構文でエミュレートできます。 少し厳格な点があります。条件はブール値に評価されなければならず、if let を使わない場合、パターンマッチングは網羅的でなければなりません。 Rustは正しさの概念を促します。

背景によっては、パターンマッチングは初めてかもしれません。 その用途は、バリアントに対する単純な分岐から、複雑なパターンの精巧なマッチングまでさまざまです。 しかし、複雑なパターンが必要になることはおそらく多くありません。 そして必要になったときには、その機能が存在することをありがたく思うでしょう！

データ表現と制御フローについて見てきました。 次は、Rustをユニークにしているものを掘り下げるときです。 この言語の最も特徴的で新しい機能、すなわち所有権です。

1. ブランチレスプログラミング。本当に重要なのか？. Jobin Johnson (2021). ↩

2. MISRA C: 2012 Guidelines for the use of the C language in critical systems (3rd edition). MISRA (2019). ↩ ↩2 ↩3

3. トレイト std::iter::Iterator. The Rust Team (2022年アクセス). ↩

Rust: 所有権の原則（4/6）

所有権の仕組みに入る前に、その動機、すなわちメモリ管理を理解しておく必要があります。

メモリを割り当てることはたいてい簡単で、変数宣言時に行われます。 固定サイズ型（例: [T; N]）はスタックに割り当てることができ、動的サイズ型（例: Vec<T>）はヒープに割り当てなければなりません。

メモリの割り当て解除（別名「解放」）こそが厄介な部分です。 従来、戦略は2つありました。自動ガベージコレクションと手動メモリ管理です。 Rustは¹、3つ目のアプローチである所有権を導入しています。 以下の表は、おおよその比較を示しています。

ガベージコレクションの性能上のペナルティには説明が必要です。 問題は、回収が言語ランタイム（あなたのプログラムに同梱される別のプログラム）によって実行される非同期操作であることです。 つまり、予測しにくい間隔で、他のコードが実行されている間、あなたのプログラムは「一時停止」されます。 ガベージコレクターは CPU 時間を消費し、あなたのプログラムがその役割を果たすのを一時的に妨げます。

手動管理アプローチの安全性上の欠点を本当に理解するために、次章ではメモリ破壊エクスプロイトを書きます。

所有権の導入

では、Rust における所有権とは何でしょうか。 大まかに言えば、プログラム内のすべての値について、次の2つの情報を決定するための仕組みです。

1. 有効なスコープ: その値が有効であり、したがって使用できる場所。

2. アクセス種別: 有効な値への参照をどのように使用できるか（読み取り専用か、書き込み可能か）。

参照については、その有効なスコープは Rust ではライフタイムと呼ばれます。 他のほとんどの言語では、スコープとライフタイムは別個の概念です。 しかし Rust の所有権モデルは、その境界を曖昧にします。

• C 系の言語では、すでに解放された（そのライフタイムは終了した）後でも、変数がスコープ内にあるため、参照によってその変数にアクセスできてしまいます。その結果は UB です。

• Rust では、それはコンパイル時エラーになります。安全なアクセスだけが許可されるため、スコープとライフタイムは重なっていなければなりません。

健全に推論するために、コンパイラはプログラム内のすべての値についてライフタイム情報を必要とします。

• 直接保持される値（参照の背後にない値）については、ライフタイムは自明です。現在それを所有しているなら、その値は生存していなければなりません。

• 参照の背後にある値については、多くの場合、ライフタイムを自動的に推論できます（これはライフタイム省略と呼ばれます）。それ以外の場合は、プログラマーが明示的に注釈を付けなければなりません。

ライフタイムは実行可能ファイルに存在しますか？

いいえ、ライフタイムはコンパイル時の構成要素です。 生成される機械語コードには現れず、コンパイラがプログラムの安全性を解析するためにのみ使用されます。 実行時のチェックもコストもありません。

すべての値には、単一で一意な所有者があります。 ソースコード上で所有者がスコープから「ドロップ」するまさにその場所（たとえば、それが宣言された関数の終端）で、その所有者が所有するすべての値のライフタイムは終了します。 そのため、コンパイラは所有されているすべての値を割り当て解除（別名「解放」）するコードを自動的に挿入します。

その結果、ソースコードに基づいてメモリとリソースの使用を正確に制御できます。 C や C++ が提供するものに匹敵しますが、安全性と引き換えに追加の制約があります。

以上が大まかな原則ですが、コードには微妙な点があります。 ルールと、それに対する例外という形でです。 このセクションと次のセクションの両方で、所有権を詳しく見ていきます。

メモリリークとは何ですか？管理戦略ごとには？

「メモリリーク」は、ある値がプログラムによって使われなくなったにもかかわらず、割り当て解除されない場合に発生します。 これは「情報漏えい」（機密情報を誤って露出させること）とは別のものです。 情報漏えいとは異なり、メモリリークはセキュリティ上の問題ではありません。

ただし、可用性には影響する可能性があります。 長時間実行されるプロセス（例: Web サーバー）が（例: ループ内で）繰り返しメモリをリークすると、最終的に利用可能な RAM を使い果たし、OS によって強制終了される可能性があります。

リークの起こり方は、メモリ管理戦略によって異なります。

• ガベージコレクション - コレクターのコードには、値のライフタイムに関するソースレベルの情報がありません。実行時に参照を追跡しなければなりません。そして保守的でなければなりません。つまり、生存している可能性がある値は回収できません。アプリケーション固有のエッジケースによって、値への参照が無期限に保持され、リークが発生することがあります。

• 手動 - たとえ元の割り当てを遠く離れたライブラリコードが行っていたとしても、プログラマーが値を手動で解放し忘れれば、リークが発生します。

• 所有権 - リークが起こり得るのは、プログラマーが循環参照を伴う内部可変性（このセクションの最後を参照）のような特定のパターンを選択した場合に限られます。

所有権の階層

すべての値はちょうど1つの所有者を持たなければならないため、所有権は階層的な木として考えることができます。 木の各ノードは値であり、親の値はその子の値を所有します。

これは、すべてのプロセスがちょうど1つの親を持つ OS のプロセスツリーの構造におおよそ対応します。 完全な類推ではありませんが⁴、この例では木という考え方を定着させるために、そのまま進めます。 木は本書の中心的なテーマであり、コンピューターサイエンスにおける不朽の概念です。

次のプログラムを考えてみましょう。これは、以前の Proc 構造体を変更したバージョンを使用しています。

#[derive(Debug)]
pub enum State {
    Running,
    Stopped,
    Sleeping,
}

#[derive(Debug)]
pub struct Proc {
    name: &'static str,  // Process name (update: nicer print than u32 pid)
    state: State,        // Current state
    children: Vec<Proc>, // Children (update: now owned!)
}

impl Proc {
    pub fn new(name: &'static str, state: State, children: Vec<Proc>) -> Self {
        Proc {
            name,
            state,
            children,
        }
    }
}

fn main() {
    // Build process tree using 3 "moves" (more info soon):
    //
    // init
    //  |- cron
    //  |- rsyslogd
    //      |- bash
    //
    // Run "pstree -n -g" (in container) to see your OS's real process tree!

    // Alloc bash
    let bash = Proc::new("bash", State::Running, Vec::new());

    // Alloc rsyslogd, 1st move: bash -> rsyslogd
    let rsyslogd = Proc::new("rsyslogd", State::Running, vec![bash]);

    // Alloc cron
    let cron = Proc::new("cron", State::Sleeping, Vec::new());

    // Alloc init, 2nd and 3rd moves: cron -> init, rsyslogd -> init
    let init = Proc::new("init", State::Running, vec![cron, rsyslogd]);

    // Print serialized tree to see ownership hierarchy
    dbg!(init);
}

このコードは、一連のムーブを使用して木（他の Proc 構造体を再帰的に含む Proc 構造体）を構築します。 ムーブは、所有権を移転する方法です。 次のセクションでは、このコードのムーブのシーケンスを調べます。 ここでは最終的な出力に注目しましょう。

[src/main.rs:49] init = Proc {
    name: "init",
    state: Running,
    children: [
        Proc {
            name: "cron",
            state: Sleeping,
            children: [],
        },
        Proc {
            name: "rsyslogd",
            state: Running,
            children: [
                Proc {
                    name: "bash",
                    state: Running,
                    children: [],
                },
            ],
        },
    ],
}

Proc は Debug トレイトを導出しているため、dbg! マクロを使ってその内容のシリアライズを出力できます。 上で出力されている 4 つの Proc 値（init、cron、rsyslogd、bash という名前）にはすべて所有者があり、それは出力されたツリーで確認できます。 最も低く深いネスト階層から、下から上へ見ていくと次のようになります。

• bash は rsyslogd に所有されています。
• rsyslogd は init に所有されています。
• cron も init に所有されています。
• init は別の値に所有されているのではなく、関数 main に所有されています。

これから、この所有権の階層がメモリの割り当てと解放にどのように影響するかを順に見ていきます。

静的ライフタイム

ここでの細かな点は name フィールドです。 その型である &str は、不変の文字列参照です。 &'static str は、名前が 文字列リテラル であり、そのライフタイム（'static）が、main 関数の前後も含むプログラムの 実行全体 にわたることを意味します（その間に OS はセットアップとティアダウンのタスクを行います）。

私たちの値はいずれも、その文字列名（"init"、"cron"、"rsyslogd"、"bash"）を 所有 していません。 それらは「永久に」生存する（プロセス終了まで生存する）何かへの参照（&）を 借用 しているだけであり、解放する必要はありません。 これらの文字列はコンパイル済みバイナリに埋め込まれています。

割り当て

各 Proc 構造体のメモリは、変数宣言時に割り当てられました。 各インスタンスは固定サイズで、64 ビットマシンではわずか 48 バイトです⁵。

#[test]
fn test_size() {
    assert_eq!(core::mem::size_of::<Proc>(), 48);
}

固定サイズであることは割り当てには便利ですが（48 バイトの塊を切り出すだけで済みます）、奇妙に思えるかもしれません。 結局のところ、Proc の children フィールドは動的なリストです。 各子はそれぞれ 48 バイトのインスタンスであり、それぞれがさらに独自の子を持つ可能性があります。 定義されている Proc は再帰的な構造です。 さらに、name は任意の長さを持つことができます。 では、どうしてサイズを固定でき、これほど簡単に割り当てられるのでしょうか。

それは、Proc のサイズ計算には、その名前と子のリストへの ポインタ⁵ だけが含まれるためです。 子を持たない単一の Proc 構造体がメモリ上でどのように見えるかを、おおよそ示すと次のようになります。

1 つの子を持つ場合（その子自身は子を持たない）は、次のようになります。

構造体のサイズは変わっておらず、指し示されているスロットの内容だけが変わっています。 上の図に注目してください。これは、"proc_1" という名前の構造体が "proc_2" という名前の構造体を所有しているとき、メモリがおおよそどのように見えるかを示しています。 まもなく、1 つの構造体が別の構造体への参照を 借用 する、別のレイアウトと対比します。

解放

では、所有権は解放をどのように扱うのでしょうか。

先ほど見た dbg! の出力にある階層を使って考えます。 init は「トップレベル」の値であり、他の 3 つを所有しています。 そして、main 関数の実行が終わると ドロップ されます。 そのためコンパイラは、main の最後の行である dbg!(init); の直後に解放ロジックを追加します。 デストラクタ は自動的に実装されます。 このデストラクタは所有権の階層をたどることで、init に所有されている他の構造体をどのようにクリーンアップすればよいかを把握しています。

println! を 1 つ追加するだけで、実行時の解放シーケンスを追跡できます。 Rust は、ある型に Drop トレイト⁶ を実装するだけで、デストラクタの前に任意のロジックを実行できます。 外部リソースを解放するためのカスタムコード（たとえばネットワーク接続やデータベース接続を閉じるなど）や、それに類する処理を実行する必要がある場合に使えます。

今回は、ドロップのたびに name フィールドと Proc 構造体のメモリアドレスを出力します。

impl Drop for Proc {
    fn drop(&mut self) {
        println!("De-alloc-ing \'{}\' Proc @ {:p}", self.name, self);
    }
}

ここでプログラムを実行すると、（シリアライズされた dbg! の出力の後に）次のように出力されます。

De-alloc-ing 'init' Proc @ 0x7ffd4d149460
De-alloc-ing 'cron' Proc @ 0x560d2fbb0b10
De-alloc-ing 'rsyslogd' Proc @ 0x560d2fbb0b40
De-alloc-ing 'bash' Proc @ 0x560d2fbb0ad0

関数 main が終了する直前に、構築したプロセスツリー全体がクリーンアップされていることが分かります。 ガベージコレクションとは異なり、この一連のイベントは予測可能です。 ソース内でデストラクタを手動で呼び出してはいませんが、経験豊富な Rust 開発者なら何が起こるかを推測できます。 このようにプログラムを書くことで、メモリ使用量をきめ細かく制御できました。

頭の体操をしたい気分なら、名前がこの特定の順序で出力される理由（ヒント: 決定的です）と、最初のアドレスが次の 3 つと異なって見える理由（ヒント: どの 2 つの 場所 が関わっているでしょうか）を少し考えてみてください。

Resource Acquisition is Initialization (RAII)

先ほど見た割り当て/解放の戦略は、より一般的には RAII と呼ばれ、特に C++ の世界でそう呼ばれます。 Scope-Bound Resource Management (SBRM) という用語を好む人もいます。

RAII/SBRM の中心的な考え方は、リソース（たとえばメモリ、ファイルハンドル、ロックなど）はコンストラクタで 取得 され、構築された値のライフタイム/スコープの間は使用でき、デストラクタで 解放 される、というものです。

Rust のコンパイラは、メモリについて常にこの振る舞いを強制します。 std::fs::File⁷ のような型や、Drop を実装したユーザー定義型は、メモリ以外のリソースについても同じことができます。

これで、所有権がメモリ管理、つまり割り当てと解放にどのように関係するかを直接見てきました。 その動機を理解したところで、所有権システムを効果的に使うために必要な概念へ移りましょう。 特に重要な 2 つは、ムーブ（所有権の移転）と 借用（所有されている値へのアクセスを一時的に貸し出すこと）です。

ムーブ

所有権をある値から別の値へ移転（別名「ムーブ」）できなければ、Rust は実用性に乏しいおもちゃの言語になってしまうでしょう。 ムーブ は、次のような日常的なプログラミングタスクを可能にします。

• 関数から値を返す。
• 計算結果を変数に格納する。
• ベクターやハッシュマップのような状態を持つコレクションを使用する。

上のプロセスツリーの例では、ムーブによって、他の Proc を含む Proc という複雑なネスト構造を段階的に組み立てることができました。 しかし、まずはもっと単純なものから始めましょう。

fn main() {
    let x = "Hello!".to_string();
    let y = x; // x は y にムーブされる。y が String 値 "Hello!" を所有するようになる

    // これは動作する
    println!("Owned string: {y}");

    // これはコンパイル時エラーになる。x は「なくなって」おり、その値はムーブ済み！
    //println!("Owned string: {x}");
}
// スコープの終わり。ここで y がドロップされる。

代入 let y = x; は、ヒープに割り当てられた String のコピーを作成したわけではありません。 長い文字列ではそれは高コストになるため、データ複製関数を明示的に呼び出す必要があります（例: let y = x.clone();）。 Rust はパフォーマンスを優先します。

代わりに、所有権の安価な移転を行いました。つまり、x から y（スタック変数）へのファットポインターのムーブです。 String 値は任意の時点で一意の所有者を 1 つしか持てないため、x は所有権を y に移すことでそれを「手放した」のです。

代入文が実行された後、y が唯一の所有者になります。 x は未初期化の空の状態のままになります。 そのため、もはやそれを使用したり出力したりすることはできません。 視覚的には、状況は次のようになります。

その概念を念頭に置いて、ツリーの構築においてムーブがどのように行われたかを見直してみましょう。 最初の 2 行は次のとおりでした。

// bash を割り当て
let bash = Proc::new("bash", State::Running, Vec::new());

// rsyslogd を割り当て、1 回目のムーブ: bash -> rsyslogd
let rsyslogd = Proc::new("rsyslogd", State::Running, vec![bash]);

vec! マクロは、新しい Vec を作成して要素をその中にプッシュするための初期化の省略記法であることを思い出してください。 ベクターに要素を追加するとき、私たちはムーブを行っています。 代入 let y = x; と同様に、Rust はデータを暗黙的に複製しません。

つまり、rsyslogd プロセスを作成することで、値（Proc 構造体のインスタンス）をローカル変数 bash からローカル変数 rsyslogd の children フィールドへとムーブしました。 すべての値はちょうど 1 つの所有者を持たなければならないため、以前の x と同様に、変数 bash はもはや使用できません。 それを出力しようとしたとしましょう。

// bash を割り当て
let bash = Proc::new("bash", State::Running, Vec::new());

// rsyslogd を割り当て、1 回目のムーブ: bash -> rsyslogd
let rsyslogd = Proc::new("rsyslogd", State::Running, vec![bash]);

// エラー: 所有者のない値は出力できません！
dbg!(bash);

このコードはコンパイルされません。

error[E0382]: use of moved value: `bash`
  --> src/main.rs:70:10
   |
64 |     let bash = Proc::new("bash", State::Running, Vec::new());
   |         ---- move occurs because `bash` has type `Proc`, which does not implement the `Copy` trait
...
67 |     let rsyslogd = Proc::new("rsyslogd", State::Running, vec![bash]);
   |                                                               ---- value moved here
...
70 |     dbg!(bash);
   |          ^^^^ value used here after move

For more information about this error, try `rustc --explain E0382`.

なぜでしょうか？ 解放について思い出してください。 ムーブは単一の所有者を維持しなければならず、それによって所有された値を格納しているメモリをいつ解放してよいかが明確（曖昧でない状態）になります。

上の誤ったコードは、特定の Proc インスタンスの所有権を rsyslog に渡そうとしながら、同時に bash の所有権も保持しようとしています。 そうすると解放が曖昧になります。コンパイラは、そのインスタンスのリソースを最終的に解放する責任が 2 つのうちどちらにあるのかを判断できません。

わかりました。 これで、なぜムーブは所有権を移転しなければならないのかについて感覚をつかめました。 しかし、これは制約が強いように感じます。 大規模で複雑なプログラムを書いている場合はどうでしょうか？ 変数を出力したり、さらにはアクセスしたりする能力を失うことは、すぐに不満の種になるでしょう。 完全な障害にならないとしてもです。 ここで 借用 が登場します。

借用とライフタイム

借用は、値へのアクセスを一時的に許可する仕組みです。 その値をムーブして元の所有者を空にすることはありません。

この概念は抽象的に感じるかもしれないので、実用的な例、つまり関数の引数から始めましょう。 以下のプログラムは以前の文字列の例に似ていますが、今回は文字列パラメーターの長さを出力する関数によってムーブが行われます。 最後の行がコメントアウトされていなければ、ムーブに関連する別のコンパイル時エラーが発生します。

fn print_str_len(s: String) {
    println!("\'{}\' is {} bytes long.", s, s.len());
}

fn main() {
    let x = "Hello!".to_string();

    // x は関数にムーブされ、その関数が String 値 "Hello!" を所有するようになる
    print_str_len(x);

    // これはコンパイル時エラーを引き起こす。x は「なくなって」おり、その値はムーブ済み！
    //println!("Owned string: {x}");
}

1 つの潜在的な修正方法は、print_str_len が入力の String を返すようにして、それを x に再代入できるようにすることです。 本質的には、関数型スタイルで行ったり来たりムーブするということです。 しかし、借用はよりよい方法を提供します。 このコードはコンパイルされ、実行されます。

fn print_str_len(s: &String) {
    println!("\'{}\' is {} bytes long.", s, s.len());
}

fn main() {
    let x = "Hello!".to_string();

    // 関数は参照によって x を一時的に借用する。
    print_str_len(&x);

    // 今回はエラーにならない！x は依然として String を所有している。
    println!("Owned string: {x}");
}

• print_str_len のパラメーターが String（「文字列」）から &String（「文字列への不変参照」）に変わりました。

  • 小さな詳細: &str 型を使うとさらによかったでしょう。そうすれば、print_str_len は文字列スライスに対しても動作できるようになるためです。静的ライフタイムを持つものも含まれます。

• 呼び出し元は、参照によって x を借用するようになりました（print_str_len(x); が print_str_len(&x); に更新されました）。

  • 重要な概念: 関数はもはや所有権を受け取りません。出力を行うのに十分な時間だけ、文字列へのアクセスを借用するだけです。

借用には従わなければならない規則があり、前の章で可変エイリアシングについて議論したときにそれに触れました。 それらの規則については次のセクションで戻ってきます。 借用によって Proc ツリーの例がどのように変わるかを見てみましょう。

#[derive(Debug)]
pub struct Proc<'a> {
    name: &'static str,          // Process name
    state: State,                // Current state
    children: Vec<&'a Proc<'a>>, // Children (update: now borrowed!)
}

impl<'a> Proc<'a> {
    pub fn new(name: &'static str, state: State, children: Vec<&'a Proc>) -> Self {
        Proc {
            name,
            state,
            children,
        }
    }
}

fn main() {
    // Alloc bash
    let bash = Proc::new("bash", State::Running, Vec::new());

    // Alloc rsyslogd, 1st move: bash -> rsyslogd
    let rsyslogd = Proc::new("rsyslogd", State::Running, vec![&bash]);

    // Print owned value (new!)
    dbg!(&bash);

    // Alloc cron
    let cron = Proc::new("cron", State::Sleeping, Vec::new());

    // Alloc init, 2nd and 3rd moves: cron -> init, rsyslogd -> init
    let init = Proc::new("init", State::Running, vec![&cron, &rsyslogd]);

    // Print another owned value (new!)
    dbg!(&cron);

    // Print serialized tree to see ownership hierarchy
    dbg!(&init);
}

大きな違いは 2 つあります。

1. 借用を使うことで、bash と cron を dbg! で出力するためにアクセスする柔軟性が得られました。ツリーに追加した後でさえ可能です。これは、追加がもはやムーブを行わないためです。children は Proc 構造体によって借用されるだけであり、別の場所で「生きる」ことができます。

2. Proc 構造体定義と、そのコンストラクター引数の 1 つに ライフタイム 注釈（'a）を追加しました。これまで使ってきた 'static ライフタイムは、値（ここでは name）がプログラム全体にわたって生存することを示しますが、'a は Proc が、それが借用する参照（ここでは所有されていない children）と少なくとも同じ長さだけ生存しなければならないことを示します。

ライフタイム注釈は、特にジェネリクスと一緒に現れると、威圧的に見えるかもしれません。 Rust のシグネチャは、ときどき少し込み入ったものになることがあります。 今の時点でこの記法やその背後にある概念に慣れている必要はありません。これは時間と経験とともに感覚がつかめるものです。 本書を通じて、これには繰り返し戻ってきます。

なぜコンパイラにはライフタイム注釈が必要なのでしょうか？

Rust のコンパイラは、特定の結果を 1 つの関数ごとに見て計算する必要があります。なぜなら、考えられるすべての関数呼び出し列を全体的な「呼び出しチェーン」として考慮することは、非常に高コストだからです。

しかし、計算された結果は、考えられるすべての呼び出しチェーンに対して妥当である必要があります。 この種のものを指す技術用語は「手続き間静的解析」です。 構造体や関数に付けるライフタイム注釈は、こうした種類の解析を支援します。 手短に言えば、ライフタイム注釈は、人間参加型の性質検証システムを可能にします。 コンパイラは、ときどきあなたの天才的な生身の脳にそれを問い合わせることで、あなたの意図を学習し、そうでなければ手に負えない問題、すなわちメモリエラーの排除を解く手助けをします。 それは、ほぼ全知でありながら狭い範囲に集中する完璧主義者と一緒にペアプログラミングをするようなものです。

うげ、ライフタイム注釈っていつも書き出さないといけないの？

幸い、その必要はありません！ ライフタイム情報は常に存在していなければなりませんが、多くの場合は自動的に推論できます。 実際、コンパイラには先ほどの print_str_len 関数が次のように見えています。

#![allow(unused)]
fn main() {
fn print_str_len<'a>(s: &'a String) {
    println!("\'{}\' is {} bytes long.", s, s.len());
}
}

静的解析により、その文字列参照が有効なライフタイムを持つことが保証され、安全性とメモリ管理が処理されます。しかも、それを明示的に書き出す必要はありません。

視覚的には、子を持たない単一の Proc 構造体について、借用ベースのメモリレイアウトは次のようになります。

そして、子を 1 つ持つ Proc（その子自身は子を持たない）の場合は次のようになります。

親プロセスは子への参照を保持し、そのライフタイムをコンパイラがチェックします。 これを、以前のムーブベースの図と比較してみましょう。

• 借用では、解放に関する限り、各構造は独立したままです。

• 構築した論理ツリーは変わりません。上記の借用ベースのプログラムの完全な出力では、[src/main.rs:73] で始まる行にそれを確認できます。

[src/main.rs:61] &bash = Proc {
    name: "bash",
    state: Running,
    children: [],
}
[src/main.rs:70] &cron = Proc {
    name: "cron",
    state: Sleeping,
    children: [],
}
[src/main.rs:73] &init = Proc {
    name: "init",
    state: Running,
    children: [
        Proc {
            name: "cron",
            state: Sleeping,
            children: [],
        },
        Proc {
            name: "rsyslogd",
            state: Running,
            children: [
                Proc {
                    name: "bash",
                    state: Running,
                    children: [],
                },
            ],
        },
    ],
}
De-alloc-ing 'init' proc @ 0x7ffe455e5c40
De-alloc-ing 'cron' proc @ 0x7ffe455e5bf0
De-alloc-ing 'rsyslogd' proc @ 0x7ffe455e5ae0
De-alloc-ing 'bash' proc @ 0x7ffe455e5a90

このツリーのムーブで構築したバリエーションと借用で構築したバリエーションの違いは、今すぐ完全に腑に落ちる必要はありません。 これらは、コンパイラ設計とコンピュータアーキテクチャの交差点にある難しい概念です。 しかし、これらすべてがどのようにつながっているのか、少し感覚がつかめ始めているかもしれません。

まとめ

所有権は Rust の最も斬新な機能ですが、同時に最も複雑な機能でもあります。 ここまで所有権について学んだことを振り返ってみましょう。

• これはメモリの割り当てと解放を管理する、高速で安全な方法です。

• すべての値には所有者があります。所有権の移転はムーブと呼ばれます。

• 値は、その所有者がスコープを抜けたときに解放されます。そのスコープは、Rust では実質的にライフタイムです。

• 値は参照を通じて借用できます。不変かつ非排他的に、または可変かつ排他的に借用できます。どちらも、値をムーブせずに一時的なアクセスを許可する方法です。

• 借用は、参照先の値より長く生存することはできません。借用は必然的に、より短いライフタイムを持ちます（名前が示すように、借用は一時的なものです）。

これら 5 つの箇条書きが大まかな直感として結びつき始めているなら、順調です。 そして、所有権システムを日々扱うためのコードパターンを、より詳しく見ていく準備ができています。

この概念の集中砲火は今は難解に感じるかもしれませんが、所有権はやがて、時間と練習を通じて身についていきます。 これは物事を行ううえで異なる方法ですが、慣れていけるものです。 さらに探っていきましょう。

1. 「所有権」は Rust が発明したものではなく、線形型とアフィン型に関する先行研究に基づいています。さらに、コンパイル時メモリ管理を行う所有権ベースの「領域解析」は、Cyclone という秘教的な言語に登場していました。しかし、メモリを管理するために所有権の強制を使用する、主流で商業的に実用可能な言語としては、Rust が初めてです。 ↩

2. Discord が Go から Rust に移行する理由。Jesse Howarth（2020）。 ↩

3. SoK: メモリにおける永遠の戦争。Laszlo Szekeres、Mathias Payer、Tao Wei、Dawn Song（2012）。 ↩

4. この類推は完全ではありません！Linux では、最初に実行されるプロセスである init には親がありません。同様に、&'static ライフタイムを持つ Rust の値は、プログラム内のどの変数にも所有されません。親プロセスは、その子も終了させることなく kill できます。Rust では、所有者がスコープを抜けると、その所有者が所有するすべての値も解放されます。 ↩

5. assert している 48 バイトのサイズには、children のヒープデータへの fat pointer（メモリアドレス、総容量、現在の長さのタプル）だけが含まれています。同様に、name フィールドは読み取り専用メモリにハードコードされた文字列へのポインタです。 ポインタは単なるメモリアドレスであり、マシン固有の幅を持ちます。そのため、このサイズが「64 ビットマシン」向けであるという注意書きをしています。 ↩ ↩2

6. トレイト std::ops::Drop。The Rust Team（2022 年参照）。 ↩

7. 構造体 std::fs::File。The Rust Team（2022 年参照）。 ↩

Rust: 実践における所有権（全6回中5回）

Rust は、所有権を柔軟かつ実用的にするための4つの仕組みを提供します。 基本原則を守りながら、プログラム全体で所有権が移り変わるための方法です。

そのうちの2つ、ムーブと借用はすでに見てきましたが、全体像を一通り見渡すことには十分な価値があります。 これらは、所有権の実装と強制を担うコンパイラコンポーネント¹である借用チェッカーとうまく付き合うための「コツ」です。

借用チェッカーを納得させるのは難しい場合があります。 Rust に慣れていないプログラマーは、プログラムを表現しようとしたときにエラーに遭遇する「借用チェッカーとの戦い」を経験するかもしれません。 幸いなことに、こうした障害の大部分は経験を積むにつれて消えていきます。

このセクションでは、次の内容を通じて、所有権についての議論を続けます。

• 新しい視点から課題の動機付けを行う。
• ASCII による可視化でライフタイムを説明する。
• 借用チェッカーと付き合うための4つの仕組みをすべて列挙する。

アシュアランスの目標を念頭に置く

コードスニペットに戻る前に、私たちの動機を改めて確認しましょう。 なぜ、これらの複雑な所有権の概念を学ぶ価値があるのでしょうか。

Rust コンパイラは、人間がループに入る性質検証エンジンに似ている、と言うこともできるでしょう。 機械と人間の融合です。 これは大げさな概念化です。 しかし、そこには一定の真実があります²。

• 利点: 機械は、性能上の制約のもとでメモリ安全性を保証するための解析を実行します（証明される性質）。

• 部分的な自動化とのトレードオフ: 機械が行き詰まったときに助けとなるよう、人間がライフタイムのソースアノテーションを管理します。あるいは、ときには問題を完全に捉え直して、機械で検査可能な形にします。

  • コンパイラエラーのフィードバックループ: Rust のコンパイル時エラーは、多くの場合、非常に実行可能な対処を示します。しかし、それらは複雑でもあり、頻繁に発生することもあります。これは不完全なフィードバックチャネルです。

この協働がうまくいけば、大きな成果が得られます。 メモリ安全性の脆弱性がなく、一般的な信頼性（例: 厳格なエラー処理）を重視した、高性能なプログラムが得られます。 これは高アシュアランスソフトウェアの堅実な出発点です。

Computers and Humans Exploring Software Security（CHESS）

CHESS は、「米国政府、軍、および経済が依存している複雑なソフトウェアエコシステムに適した規模と速度で 0-day 脆弱性を発見することを目標として、コンピューターと人間がソフトウェア成果物について協働で推論できるようにすることの有効性」に関する DARPA の研究プログラム³でした⁴。

これは、詳細なセキュリティ評価がスケールさせるのが難しい専門家プロセスであるという事実への対応です。 Rust は CHESS プログラムにおける解決策とは見なされていませんでした。 すべての基準を満たすことはなかったでしょう。 しかし、これをライフサイクルにおけるシフトレフトと考えることはできます。つまり、借用チェッカーに支援された開発者は、評価者が発見すべきメモリ破壊バグを持ち込まない、ということです。

その観点から見ると、Rust には驚くほど高い**投資対効果（ROI）**があります。 Rust が早期に防ぐバグは、資産のライフサイクルの後半で修正する方が高くつきます。

• 本番環境へのパッチ適用には、顧客ごとのコストとリスクが伴います。
• コンパイラエラーに従うことには、それがありません。

スコープとライフタイム

前述したように、ほとんどのプログラミング言語では、スコープとライフタイムは別々の概念です。

• スコープとは、値にアクセスできるコードの範囲です。

  • 値がグローバルでない限り、通常は関数内、つまり多くの言語では { と } の括弧の間を意味します。

• ライフタイムとは、値が有効な状態にある期間です。

  • ガベージコレクションを備えた言語では、それは値への参照が存在する限りです。システム言語では、値が解放されるまでである場合があります。

Rust の借用チェッカーは、これら2つの概念の境界を曖昧にします。 借用チェッカーは、スコープに基づくライフタイムの強制に執拗にこだわります。

これらの考え方がどのように展開するのか、他の情報源から借りた例⁵で感覚をつかみましょう（意図した洒落です）。 まず、小さな C++ コードスニペットから始めます。

#include <iostream>

int main() {
    int *p; // 整数へのポインター

    { // スコープ S の開始
        int x = 1337;   // 値
        p = &x;         // 値への参照
    } // スコープ S の終了

    // x を出力すると未定義動作が発生します！ :(
    std::cout << "x = " << *p << std::endl;
    return 0;
}

C++ には借用チェッカーがないため、このプログラムは警告なしでコンパイルされます⁶。 そして、この関数の最後にある出力（std::cout で始まる行）は UB を引き起こします。 より大きなプログラムの文脈では、どのような UB もクラッシュやエクスプロイトにつながる可能性があります。

問題は、すでにスコープ外になった値（x）への参照（p）を使おうとしていることです。 出力時点では、x のライフタイムは終わっています。 Rust で同じことを試したときに、借用チェッカーが何と言うか見てみましょう。

fn main() {
    let p; // 整数への参照

    { // スコープ S の開始
        let x = 1337;   // 値
        p = &x;         // 値への参照
    } // スコープ S の終了

    // コンパイル時エラー！
    println!("x = {}", p);
}

次のエラーが出力されます。

error[E0597]: `x` does not live long enough
  --> src/main.rs:6:13
   |
6  |         p = &x;         // 値への参照
   |             ^^ borrowed value does not live long enough
7  |     } // スコープ S の終了
   |     - `x` dropped here while still borrowed
...
10 |     println!("x = {}", p);
   |                        - borrow later used here

このコンパイラエラーを少し時間を取って読んでみてください。 読者によっては、複雑なコンパイラエラーがある程度意味を持ち始めるのは、ここかもしれません。 借用チェッカーはライフタイムの問題について不満を述べています。 それは正当なことです。 ここで関係している2つのライフタイム（'a と 'b）を書き出すことができます。

fn main() {
    let p;                  // ---------+-- 'a
                            //          |
    {                       //          |
        let x = 1337;       // -+-- 'b  |
        p = &x;             //  |       |
    }                       // -+       |
                            //          |
    println!("x = {}", p);  // ---------+
}

借用は、参照先の値より長く存続できないことを思い出してください。 上記では 'a が 'b より長く存続するため、借用チェッカーがこのプログラムを拒否するのは正当です。 x の定義を包み込むネストされたスコープ S がなければ、C++ でも Rust でもこの問題は発生しません。 これは問題ありません。

fn main() {
    let p;                  // ---------+-- 'a
                            //          |
    let x = 1337;           // -+-- 'b  |
    p = &x;                 //  |       |
                            //  |       |
    println!("x = {}", p);  // -+-------+
}

ここでは、借用のライフタイム（'b）は、借用される値のライフタイム（'a）の厳密な部分集合です。 どのルールにも違反していません。

さて、関数内のネストされたスコープはそれほど一般的ではないため、この例は作為的に感じられるかもしれません。 それはもっともです。 これは概念を説明するためだけのものです。 より現実的な例としては、スタック上のローカル変数への参照を返す、変数を二重に解放する、解放済みの値を読み取る、などが考えられます。 私たちの例におけるネストした波括弧と同様に、これらのケースでもライフタイムの不一致が発生する可能性があります。

コードベースの規模と複雑さが増すと、ライフタイムを手作業で推論することは難しくなります。 そして、たった 1 つのミスであっても、信頼性やセキュリティ、あるいはその両方を危険にさらす可能性があります。

柔軟性の仕組み

所有権を実世界のプログラムの出荷と両立させるには、多少の余地が必要です。 単一所有者ルールの中に、少しの融通が必要です。 ここからは、これらの柔軟性の仕組みを概観し、本書全体で使用していきます。

1) 所有権をムーブする

前のセクションでムーブを見ました。 ライフタイムについてよりよく理解できたので、前のセクションの最初の Proc ツリーの例、つまり借用ではなくムーブを使用した例を振り返ってみましょう。

以下の右側の ASCII グラフは、各変数の値が別の変数へムーブされたときに、その変数のライフタイムがどのように終了するかを示しています。

// bash を割り当て                                                   //
let bash = Proc::new("bash", State::Running, Vec::new());           // ---------+-- 'a
                                                                    //          |
// rsyslogd を割り当て、1 回目のムーブ: bash -> rsyslogd              //          |
let rsyslogd = Proc::new("rsyslogd", State::Running, vec![bash]);   // ---------+-- 'b
                                                                    //          |
// cron を割り当て                                                   //          |
let cron = Proc::new("cron", State::Sleeping, Vec::new());          // -+-- 'c  |
                                                                    //  |       |
// init を割り当て、2 回目と 3 回目のムーブ: cron -> init, rsyslogd -> init //  |       |
let init = Proc::new("init", State::Running, vec![cron, rsyslogd]); // -+-------+--'d
                                                                    //          |
// 所有権階層を見るためにシリアライズされたツリーを出力する           //          |
dbg!(init);                                                         // ---------+

一般に、所有権は次の方法でムーブできます。

• 値を新しい変数に代入する。
• 値を関数に渡す（参照を使用しない場合）。
• 値を関数から返す。

2) Copy トレイトを実装する型のデータを複製する

文字列と Proc 構造体について、ムーブを扱いました。これらは多くのデータを所有する可能性がある型です。

• 文字列は非常に長いかもしれず、場合によってはファイル全体の内容を含んでいるかもしれません。

• Proc インスタンスは、直接またはネストされた多数の子を持つ可能性があります。

このような場合、ムーブによって代入演算子 = は効率的になります。所有権が移転されるときに、大きなデータはコピーされません。 既知の有効なポインターを複製するだけです。

しかし、整数や文字のような一部の型では、ムーブは過剰です。 これらの型が保持するデータは非常に小さく、コピーを行うのは取るに足りないことです。短いビット列を複製するだけです。 後で解放するリソースはなく、完全な複製を安価に作成できます。 ムーブする代わりに、単にデータをコピーできます。

以下を考えてみましょう。

#![allow(unused)]
fn main() {
let x = "42_u64".to_string();
let y = x; // x は y に *ムーブ* される。y は String 値 "42_u64" を所有し、x はなくなる。

let a = 42_u64;
let b = a; // a は *コピー* され、b に代入される。値 42 のインスタンスが 2 つ得られる。

// これはコンパイル時エラーになる
//println!("Strings: {x}, {y}");

// これは動作する
println!("Integers: {a}, {b}");
}

これは次を出力します。

Integers: 42, 42

文字列 x がムーブされたのに対し、64 ビット符号なし整数 a はコピーされました。 代入操作は依然として安価でしたが、所有権を移転する代わりに、小さな複製を作成しました。

便利なのは、所有権やムーブについて考える必要がなく、独立した複製をそれぞれ別個の値として自由に使えることです。 これにより、整数や浮動小数点数のようなプリミティブ型の扱いが、はるかに人間工学的になります。 Rust のムーブセマンティクスによる認知的負荷から、ありがたい休息を得られます。

代入は、Copy トレイトを実装する任意の型に対してコピーを行います⁷。 外部に割り当てられたデータ（Vec や String フィールドなど）を保持しないのであれば、独自のカスタム型に対して Copy を derive または実装できます。

なぜ、すべてに Copy を実装させて、二度とムーブの心配をしなくてよいようにしないのでしょうか。 データの複製は、プログラムの実行時間とメモリ消費を増加させるからです。 ほとんどのユーザー定義構造体のような大きなデータの塊には、Copy は適していません。 そのため、日常的なプリミティブ型以外では、Copy トレイトは明示的にオプトインしなければなりません。

3) ライフタイムの一部だけを借用する

前のセクションで借用を見ました。 考え方は、所有権を移転する（ムーブを行う）ことも、データを複製する（コピーを行う）こともなく、参照によって値への一時的なアクセスを得られるというものでした。

復習として、参照ベースの Proc 構造体を見てみましょう（右側に追加されたライフタイム図が、前のムーブの場合とどのように異なるかに注目してください）。

// bashを確保                                                          //
let bash = Proc::new("bash", State::Running, Vec::new());               // -------------------------+-- 'a
                                                                        //                          |
// rsyslogdを確保、1回目のムーブ: bash -> rsyslogd                     //                          |
let rsyslogd = Proc::new("rsyslogd", State::Running, vec![&bash]);      // ------------------+-- 'b |
                                                                        //                   |      |
// 所有値を出力（新規!）                                               //                   |      |
dbg!(&bash);                                                            //                   |      |
                                                                        //                   |      |
// cronを確保                                                          //                   |      |
let cron = Proc::new("cron", State::Sleeping, Vec::new());              // ----------+-- 'c  |      |
                                                                        //           |       |      |
// initを確保、2回目と3回目のムーブ: cron -> init, rsyslogd -> init    //           |       |      |
let init = Proc::new("init", State::Running, vec![&cron, &rsyslogd]);   // --+-- 'd  |       |      |
                                                                        //   |       |       |      |
// 別の所有値を出力（新規!）                                           //   |       |       |      |
dbg!(&cron);                                                            //   |       |       |      |
                                                                        //   |       |       |      |
// 所有権階層を確認するためにシリアライズ済みツリーを出力              //   |       |       |      |
dbg!(&init);                                                            // --+-------+-------+------+

Rustは、参照が常に安全に使用できることを保証します。 参照は、それが参照する値よりも長く存続することはできません。 これは、参照が常に有効である期間として、参照先よりも短いライフタイムしか持てないことを意味します。 時間的メモリ安全性の問題につながる「ダングリングポインタ」は発生し得ません。 そのため、以下のMISRAルールに準拠します:

[AR, Rule 18.6] オブジェクトのライフタイムが終了するなら、参照のライフタイムも終了しなければならない⁸

さらに、「共有 XOR 可変」という有名なルールがあります。 Rustの参照は、次のいずれかになれます（ただし両方同時にはなれません）:

• &T - 不変（参照先の値を変更できない）かつ共有（複数の参照を同時に使用できる）。

  • 参照はデフォルトで不変です。

• &mut T - 可変（参照先の値を変更できる）かつ排他（任意の時点で1つだけ存在する）。

  • 参照を可変にするには明示的にマークする必要があります。

ここまでは、最初のケースだけを示してきました。これは多くの場合、共有参照と呼ばれます。 さらにRustコードを書き進めながら、2つ目のケース、すなわち可変参照を扱う方法を学んでいきます。 排他可変の制約を先取りして見ると、次のコードはコンパイルに失敗します:

let mut x = "こんにちは!".to_string();

let r1 = &mut x; // 1回目の可変借用
let r2 = &mut x; // 2回目の可変借用 - 問題!

println!("{}, {}", r1, r2);

次のエラーが出ます:

error[E0499]: cannot borrow `x` as mutable more than once at a time
 --> src/main.rs:7:10
  |
6 | let r1 = &mut x; // 1回目の可変借用
  |          ------ first mutable borrow occurs here
7 | let r2 = &mut x; // 2回目の可変借用 - 問題!
  |          ^^^^^^ second mutable borrow occurs here
8 |
9 | println!("{}, {}", r1, r2);
  |                    -- first borrow later used here

For more information about this error, try `rustc --explain E0499`.

しかし、これはOKです:

#![allow(unused)]
fn main() {
let mut x = "こんにちは!".to_string();

let r1 = &mut x; // 1回目の可変借用

// 文字列を変更する
r1.pop();
r1.push_str(", 世界");

println!("r1で変更: {}", r1);
// 1回目の可変借用の暗黙の（開閉括弧のない）スコープの終わり。
// この関数内では再び使われないため

let r2 = &mut x; // 2回目の可変借用 - OK、同時ではない!

// 別の参照を介して文字列を変更する
r2.push('!');

println!("r2で変更: {}", r2);
}

次のように出力されます:

r1で変更: こんにちは, 世界
r2で変更: こんにちは, 世界!

可変借用で難しいのは、それらが排他であり続けなければならないという要件です。 その要件を満たすことは必ずしも簡単ではありません。それは経験を通じて身につくスキルです。

4) 「内部可変性」パターン

最初の3つの所有権の「回避策」（ムーブ、コピー、借用）は、この本で必要になるすべてです。 しかし、4つ目の選択肢として、Rustでよく知られたパターンがあります。 これは内部可変性と呼ばれ、&T xor &mut Tチェックの強制を緩和します。

それでもこのルールには従わなければなりませんが、すべての可能な実行に対する相互排他をコンパイル時検証（静的保証）で証明する必要はありません。 その厳格さは、特定の問題を表現することを難しすぎるものにします。 しかし、コンパイルできれば、それは保証されています。

代わりに、内部可変性は実行時検証（動的保証）を可能にします。 以下は、内部可変性パターンでよく使われる2つの型です。 これらの型シグネチャが何を意味するかは心配しないでください。トレードオフに注目しましょう:

• Rc<RefCell<T>>の可用性リスク: コード内のある文が、別の文によってすでに可変借用されている値を可変借用しようとすると、そのスレッドはpanic!します（即座に終了します）⁹。

  • 例: シングルスレッドアプリケーションを終了させるリスクがあります。

• Arc<RwLock<T>>の潜在的なパフォーマンスへの影響: - スレッドAが、スレッドBが書き込みロックを保持している間にデータへの読み取りアクセスを要求すると、スレッドAはスレッドBがロックを解放するまでブロックされます（実行を一時停止します）。ただし、複数の読み取り側が同時に存在することは許可されます¹⁰。

  • 例: マルチスレッドアプリケーションでパフォーマンス低下のリスクがあります。

  • リーダー/ライターロックは、システムプログラミングで一般的な同期メカニズムです。Rust固有のものではありません。

繰り返しますが、この本では内部可変性を使用しません。 それなしでも機能豊富なライブラリを構築できます。 また、コンパイル時の保証には失敗し得る実行時チェックが不要であるため、私たちの実装はより高いレベルの保証を得られます。

それでも、内部可変性はいずれ学び、使う価値があります。 ある種の問題に対してはベストプラクティスであり、他のリソースで十分に取り上げられています¹¹。 ただし覚えておいてください - Rustは大きな言語です。 生産的になるために、すべての機能を習得する必要はありません。

ランタイムに関する厄介ごとからまだ抜け出したわけではありません！

私たちのコードは、たとえば arr[i] のようなインデックスベースの配列アクセスを行います。 これにより、実行時の境界チェックが発生します。 失敗（範囲外インデックスへのアクセスの試み）は、RefCell と同様に panic! を意味します。 しかし、配列のインデックス指定は推論しやすいものです。

インデックス指定のロジックに対する信頼性と、より一般的な信頼性を正当化するために、第12章ではストレステストの高度な形式である差分ファジングを紹介します。

要点

これで、所有権をより包括的に捉えられるようになりました。 借用チェッカーと付き合う4つの方法を含めてです。

1. Moving（移動）所有権をある変数から別の変数へ移すこと。

2. Copying（コピー）データを複製し、2つ目の独立した所有インスタンスを作成すること。

3. Borrowing（借用）ライフタイムの一部の期間だけデータにアクセスすること。

4. Interior mutability - 緩和された実行時の所有権強制の一形態。

以上です！ Rust プログラミング言語において最も難しく悪名高い側面を扱ってきました。 これらの概念を念頭に置きながらさらにコードを書いていけば、やがて所有権は自然に身につくものにさえなるかもしれません。

所有権はメモリ安全性を保証します。 しかし Rust は一般的な正しさ、つまりメモリ安全性を超えた堅牢性でも知られています。 その評判の大きな理由が、エラーハンドリングのあり方です。 そしてそれが次のトピックです。

1. MIR 借用チェック。Rustc 開発ガイド（2022年閲覧）。 ↩

2. あるレベルでは、これはほとんどのプログラミング言語（PL）の革新（たとえば、型システムやアノテーションベースのフレームワーク）にも当てはまります。 また、これは業界の開発ツールやプラクティス（たとえば、製品作成を支援する強力な IDE やフレームワーク、本番品質のシステムやサービスを支えるテストおよびデプロイプロセス）から得られる堅牢性の利点を補完します。Rust は特別なものでも「銀の弾丸」でもなく、多くの現代的な開発ツールの1つです。しかし Rust は重要なニッチ、すなわち高速 && メモリ安全に取り組んでいます。 ↩

3. CHESS: Computers and Humans Exploring Software Security。Dustin Fraze（2018年、パブリックドメイン）。 ↩

4. Computers and Humans Exploring Software Security (CHESS)。William Martin（2022年閲覧）。 ↩

5. 適切なクレジットを示すために述べると、この例は この StackOverflow の質問 と TRPL 本の この部分 に基づいています。特に、TRPL と同じ ASCII 図のコメントを使用しています。 ↩

6. このプログラムは、g++ バージョン 9.4.0（執筆時点で Ubuntu 20.04 LTS に同梱されていた最新バージョン）を使用し、コマンド g++ scope.cpp -o scope でコンパイルしました。警告は出力されませんでした。 ↩

7. トレイト std::marker::Copy。The Rust Team（2022年閲覧）。 ↩

8. MISRA C: 2012 Guidelines for the use of the C language in critical systems (3rd edition)。MISRA（2019年）。 ↩

9. モジュール std::cell。The Rust Team（2022年閲覧）。 ↩

10. 構造体 std::sync::RwLock。The Rust Team（2022年閲覧）。 ↩

11. RefCell<T> と内部可変性パターン。Steve Klabnik、Carol Nichols 著（2022年閲覧）。 ↩

Rust: エラー処理（6/6）

エラーの検出と処理は、一般にソフトウェア開発の基礎ですが、堅牢性と可用性を優先するソフトウェアにとっては特に差し迫ったトピックです。 エラー処理は、Rust が自身を差別化している領域の 1 つでもあります。その仕組みと綿密さの両面においてです。

大まかに言うと、エラーは次の 3 つのクラスのいずれかに分類できます。

1. コンパイル時エラー - 単一のモジュールのコンパイルを妨げる構文エラーまたは所有権エラー。Rust のコンパイラは、このような場合に実行可能な対処を示すエラーメッセージを出力する傾向があります。特に言語を学び始めたばかりの頃には、その多くを目にすることになるでしょう。ただ覚えておいてください。あなたは安全性検証プロセスを支援しているのです。

2. リンク時エラー - 複数のモジュールの合成を妨げるシンボル解決エラー。cargo のおかげで、純粋な Rust コードベースで作業しているときにリンクエラーが起きることはまれなはずです。しかし、大規模な多言語プロジェクトや、C/C++ ライブラリを依存関係として使用している場合には現れることがあります。

3. ランタイムエラー - 実行時に、破られた不変条件や操作の失敗によって引き起こされるエラー。このクラスは保証に影響します。これが本セクションの主題であり、Rust におけるランタイムエラー処理の戦略を見ていきます。

論理エラー（例: 誤ったアルゴリズムの実装）が上に挙げられていないことに注意してください。 これらは一般的なバグであり、エラー処理に関する議論の範囲外であると考えます。

本来のエラーについて、一部の開発者コミュニティでは以下の区別をします。

• 「エラー」は、プログラムが合理的に処理できない壊滅的な失敗（例: システムメモリの枯渇）を特に指します。

• 「例外」は、プログラマー定義のロジックによって「捕捉」して処理できるエラー（例: ファイルが存在しない）です。

ここではその区別はしません。 「エラー」という用語を、壊滅的なケースと処理可能なケースの両方を含むものとして使います。

Option vs Result

Rust の標準ライブラリは、失敗しうる操作を表現するために 2 つの enum 型、Option¹ と Result² を提供しています。 厳密に言えば、エラー処理が指すのは Result だけです。 しかし、この 2 つは概念的に似ており、関数の戻り値の型として広く使われているため、ここで両方を扱います。

Option

Option は、関数が潜在的に返すものを持たない可能性があることを伝えます。 操作自体は正常に完了したとしてもです。 これは通常の振る舞いです。

列挙型とジェネリクスの両方を扱ったので、この標準ライブラリ型の定義¹を解釈してみてください。

pub enum Option<T> {
    None,
    Some(T),
}

Option の定義における None バリアントにはデータが含まれていないことに注目してください。 この定義は、「何らかの型 T XOR 何もない」という概念をエンコードしています。 結果を返すかもしれない失敗しうる操作に理想的です。

後で非常に詳しく扱うことになる例として、順序付き集合の get メソッドがあります。 要素の取得は、その要素が集合に存在しない場合に None を返します。

use std::collections::BTreeSet;

let set = BTreeSet::from([1, 2, 3]);

assert_eq!(set.get(&2), Some(&2));
assert_eq!(set.get(&4), None);

概念チェックポイント

上の BTreeSet の使用例には、この章で導入した概念に関連する細かな点があります。 理解を固めましょう。

• let set: BTreeSet<i32> = ... は推論されています。i32 は Rust のデフォルト整数型であり、私たちは 3 つの整数リテラルからなる配列から集合を作成しています。

• したがって、ここで get は Option<&i32> を返します。この戻り値シグネチャにある参照演算子 & は、取得によって要素が集合の外へムーブされないことを保証します。集合は依然としてそれを所有しており、私たちはそれが存在するかを確認しているだけです。

  • 実際に要素を削除するには、別の集合メソッドである take を使います。これは Option<T>（私たちの例では Option<i32>）を返し、所有権を移転します。

• 同様に、get への引数は型 &i32 です（したがって set.get(&2 です）。探している要素の所有権を get 関数に取得させたくないからです。

  • プリミティブな整数は安価にコピーできるのに、なぜでしょうか。それは BTreeSet<T> がジェネリックコンテナだからです。集合に格納される項目は、i32 だけでなく、大きく複雑なオブジェクトである可能性があります。

Result

一方、Result にはまったく異なるユースケースがあります。 それは、関数が操作を完了できない可能性があることを伝えます。 失敗は異常であり、問題を報告する必要がある、または操作を再試行する必要があることを意味します。

Result の定義²では、両方のバリアントがデータを含んでいます。 Ok バリアントは成功した操作の出力をカプセル化し、一方 Err バリアントは失敗を示し、カスタムエラー型をカプセル化します。

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

第 2 章の CLI ツールの文脈ですでに見た例として、ファイル I/O があります。 ファイルを開こうとすると、いくつかの理由で失敗することがあります。ファイルが存在しないかもしれませんし、読み取り権限がないかもしれません。 以前は ? 演算子を使ってエラー伝播を短絡していましたが、次のようにファイルオープンの Result を明示的にマッチすることもできます。

#![allow(unused)]
fn main() {
use std::fs::File;

match File::open("/path/to/non-existent/file.txt") {
    Ok(f) => println!("Successfully opened: {:?}", f),
    Err(e) => eprintln!("Error occurred: {:?}", e),
}
}

Option とは異なり、Result は内部的に #[must_use] 属性でマークされています。 Result を返す関数を書くときは常に、呼び出し側は Ok と Err の両方のケースを明示的に処理しなければなりません。 この組み込みの強制は、別の MISRA ルールにも適しています。

[AR, Directive 4.7] 関数から返されるエラー情報を常にテストする³

Result は潜在的な失敗を表現するための便利な仕組みを提供し、自動的に処理を強制しますが、それでもエラー処理を実際に行うというアプリケーション固有のタスクは残ります。 一般に、次の 3 つのアプローチのいずれかを取ることができます。

1. 不変条件をアサートする - エラーが発生した場合、プログラムを即座に終了します。エラーから妥当に回復できない場合に有用です。

2. マージして伝播する - 複数種類のエラーを単一の不透明なエラーにマージし、呼び出し元へ渡します。無関係な詳細を隠蔽したいが、それでも呼び出し元に対応する機会を与えたい場合に有用です。

3. 列挙して伝播する - 詳細なエラー情報を呼び出し元へ渡します。呼び出し元の対応処理が、発生したエラーの正確な種類に依存する場合に有用です。

それぞれのアプローチをより具体的にし、細かな詳細をいくつか探るために、第2章の RC4 ライブラリと対応する CLI ツールに変更を加えます。

Rust のエラー vs C++ の例外

C++ では、2つのエラーハンドリング戦略が可能です⁴:

1. 戻り値コード: 関数は、-1 や NULL のような特別な値を返すことで、エラーが発生したことを暗黙的に示せます。しかし開発者は、すべての呼び出し箇所でこの特別なケースを確認し、その意味を解釈することを覚えておかなければなりません。

   • うっかりチェックをし忘れることは、C と C++ の両方で、上記の Directive 4.7 に対する一般的な違反です。

2. スローされる例外: 例外は、プログラマーが定義したハンドラー、またはそれが提供されていない場合は OS 自体によって、必ずキャッチされなければなりません。そのため、ハンドリングが強制されます。また、説明的なコンテキストを提供できる場合もあります。

   • しかし、C++ の例外は通常のコードフローの外側で発生します。非常に深くネストされた関数から伝播されるため、一見無関係に見えることがあります。これにより、関数に「見えない」終了点が導入されます。これは別の MISRA ルール（ここではまだ言及していないもの）に違反するだけでなく、一部の C++ プログラマーが例外の使用を「悪いプラクティス」と考える原因にもなります。

   • さらに、アンワインドはマルチコアシステムでは性能上のボトルネックになります（グローバルロックのため）⁵。

Result により、Rust は両方の長所を提供します。 戻り値コードと同様に、Result は通常の呼び出しチェーンを通じて上位へ渡されます。 C++ の例外と同様に、Result はうっかり無視できず、Err バリアントを通じて意味のあるコンテキストを提供します。

不変条件をアサートする

前の章では、RC4 暗号インスタンス用のコンストラクターを書きました。 慣例により、コンストラクターは new という名前の関連関数です。 私たちの new 関数は、単一のパラメーターである鍵バイト配列を受け取り、不変条件をアサートしていました。

pub fn new(key: &[u8]) -> Self {
    // 有効な鍵長を検証する（40〜2048ビット）
    assert!(5 <= key.len() && key.len() <= 256);

    // ...ここにさらにコード...
}

一方で、これは重要なルール（入力検証）に従っています。

[RR, Directive 4.14] 外部入力は検証されなければなりません³

他方で、私たちはライブラリのユーザーに代わって議論の余地がある判断をしました。提供された鍵が短すぎる、または長すぎる場合、プログラムを終了することにしたのです。 このエラー条件に到達した場合、ユーザーには対応する機会がありません。

特定の壊滅的な失敗ケースについては、Rust 言語自体も同様の判断をします。 たとえば、配列を範囲外インデックスで参照したとします。

let mut five_item_arr = [0; 5];

for i in 0..6 {
    five_item_arr[i] = i;
}

ループは i == 0 から i == 5 までの6回反復しますが、配列には有効なインデックスが5つ（0 から 4）しかありません。 このプログラムはコンパイルには成功しますが、実行時に終了し、次のように表示されます。

thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', src/main.rs:7:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

これは典型的な「off-by-one」エラーです。 テストをしていれば、このインデックス参照の失敗を捕捉する助けになったでしょう。 しかし、すべての致命的な不変条件がテストしやすいわけではないため、現実世界のほとんどのプログラムには、何らかのアサーションベースのエラーハンドリングが含まれます。 この例のような暗黙的なケースも含まれます。

テストの目的の1つは、チェックや緩和策によって、プログラムが実際にはそのようなアサーションに到達しないだけの堅牢性を持つことを示すことです。 一定数の致命的なアサーションは常に存在しますが、徹底したテストにより、プログラムがそれらを回避しているという確信を得られます。

特定の場合には、問題が起きる可能性を完全に取り除けることがあります。 たとえば、配列をイテレーターを使って初期化すれば、範囲外インデックスの可能性を排除できました。

let mut five_item_arr = [0; 5];

for (i, item) in five_item_arr.iter_mut().enumerate() {
    *item = i;
}

次に、致命的ではないケース、つまり検出して伝播できるエラーを見ていきましょう。 エラー伝播戦略を示すために、RC4 コンストラクターをリファクタリングします。

マージして伝播する

提供された鍵が正しいサイズでなかった場合、第2章の RC4 CLI はユーザーに説明的なエラーを示していたことを思い出してください。実質的には、有効な長さの鍵を再入力するよう促していました。 これは clap の num_args = 5..=256 アノテーションによって実現しました。

ライブラリ自体（CLI フロントエンドではなく）は、不変条件をアサートしていました。 フロントエンドのチェックは、このアサーションが決してトリガーされないことを保証していただけです。

このライブラリを使用する任意のプログラムに対して、フロントエンドかどうかにかかわらず、同様のチェックをライブラリに強制させたいとします。 次のように、単一の不透明なエラーを伝播させることができます。

impl Rc4 {
    /// 新しい Rc4 ストリーム暗号インスタンスを初期化する
    pub fn new(key: &[u8]) -> Result<Self, ()> {
        // 有効な鍵長を検証する（40〜2048ビット）
        if (key.len() < 5) || (key.len() > 256) {
            return Err(());
        }

        // 構造体をゼロ初期化する
        let mut rc4 = Rc4 {
            s: [0; 256],
            i: 0,
            j: 0,
        };

        // ...ここにさらに初期化コード...

        // 初期化済みの Rc4 を返す
        Ok(rc4)
    }
}

カスタムエラー型の代わりにユニット型（()、空の値）を選ぶのは、「最低限」のアプローチです。 一般的には、プライベートな内部 API により適しています。 しかし、呼び出し元は返された Result の Ok と Err の両方のバリアントに対して適切なアクションを取らなければならないため、目的は果たします。 Ok バリアントには、正常に初期化された暗号が含まれます。

列挙して伝播する

公開 API では、() よりもカスタムエラー enum の方が望ましい可能性が高いです。

#[derive(Debug)]
pub enum Rc4Error {
    KeyTooShort(usize),
    KeyTooLong(usize),
}

impl Rc4 {
    /// Init a new Rc4 stream cipher instance
    pub fn new(key: &[u8]) -> Result<Self, Rc4Error> {
        const MIN_KEY_LEN: usize = 5;
        const MAX_KEY_LEN: usize = 256;

        // Verify valid key length (40 to 2048 bits)
        if key.len() < MIN_KEY_LEN {
            return Err(Rc4Error::KeyTooShort(MIN_KEY_LEN));
        } else if key.len() > MAX_KEY_LEN {
            return Err(Rc4Error::KeyTooLong(MAX_KEY_LEN));
        }

        // Zero-init our struct
        let mut rc4 = Rc4 {
            s: [0; 256],
            i: 0,
            j: 0,
        };

        // ...more initialization code here...

        // Return our initialized Rc4
        Ok(rc4)
    }
}

上記では、単一の KeyLengthInvalid バリアントなどを使うのではなく、両方のエラー条件（短すぎる場合と長すぎる場合）を列挙することを選びました。 各バリアントにはしきい値の長さも含まれており、KeyTooShort バリアントでは最小値、KeyTooLong では最大値です。

この粒度の細かさが、このコンテキストで適切かどうかは場合によります。 ストリーム暗号ライブラリでは、一般的なパターンではないことは確かです。 しかし、この例は、さまざまな内部エラーを列挙し、それらを渡す方法を示しています。

これにより、呼び出し元はエラーの enum バリアントに対して match し、各ケースを適切に処理できます。 概念的には、次のようなものになります。

use rc4::{Rc4, Rc4Error};

let key = [0x1, 0x2, 0x3];

match Rc4::new(&key) {
    Ok(rc4) => println!("Do en/decryption here!"),
    Err(e) => match e {
        Rc4Error::KeyTooShort(min) => eprintln!("Key len >= {} bytes required!", min),
        Rc4Error::KeyTooLong(max) => eprintln!("Key len <= {} bytes required!", max),
    },
}

Error トレイト

Rust のエラーハンドリングのパズルには、もう 1 つ重要なピースがあります。それは標準ライブラリで定義されている Error トレイトです⁶。 この特殊なトレイトを私たちの Rc4Error 型に実装すると、次の 2 つの利点があります。

• Rc4Error がエラー型であることを明確に示せます。単に名前に Error が含まれている enum というだけではありません。

• このトレイトの source メソッドと [現在は不安定な] backtrace メソッドにより、より豊富なエラーレポートが可能になります。

しかし、私たちの RC4 ライブラリでこのトレイトを使わないことには、十分な理由があります。 私たちの暗号実装は #![no_std] 互換であり、任意の環境、さらには「ベアメタル」でも実行できることを思い出してください。

Error トレイトは、バックトレースを取得して出力するために必要なランタイムサポートを持つオペレーティングシステムの存在を前提としています。 したがって、#![no_std] ライブラリでは std::error::Error をインポートできません。

そのユースケースをサポートすることはできないのでしょうか？

Error トレイトを省くことが満足のいかない妥協に思えるなら、演習としてこのトレイトのサポートをフィーチャーゲートしてみてください。 そのためには、Cargo.toml⁷ ビルドファイルを変更し、cfg マクロ⁸の背後でトレイトを実装する必要があります。 慣例として、このフィーチャーは std と呼ばれ、次のように選択します。

cargo build --features="std"

依存関係は、自身の Cargo.toml エントリ内でオプションのフィーチャーを有効にすることを選択できます。

[dependencies]
rc4 = { path = "../rc4", version = "0.1.0", features = ["std"] }

これにより、両方の長所を得られます。デフォルトでは組み込みシステムをサポートしつつ、ライブラリ利用者が非組み込みターゲット向けにビルドする際にオプションのフィーチャーを有効にすれば、より豊富なエラーレポートを可能にできます。

まとめ

Rust の Result 型は、概念的に似ている Option と混同しないでください。これは、ランタイムエラーを報告し、その処理を強制するための主要な仕組みです。 C++ の例外と同様に、無視することはできません。 C++ の例外とは異なり、通常の呼び出しチェーンの一部です。

エラーハンドリングは保証に不可欠ですが、実際に取るべき具体的なアクションは最終的にはアプリケーション固有です。 各状況に応じて最適なアプローチを選択できます。不変条件をアサートする、不透明なエラーを伝播する、あるいは具体的なエラーを伝播する、といった方法です。

これで、Rust のコアコンセプトを巡る 6 部構成のツアーは終わりです！ この章の残りでは、この言語で大規模かつ野心的なシステムを構築するのに役立つ機能とツールを見ていきます。

1. 列挙型 std::option::Option。The Rust Team（2022 年閲覧）。 ↩ ↩2

2. 列挙型 std::error::Error。The Rust Team（2022 年閲覧）。 ↩ ↩2

3. MISRA C: 2012 Guidelines for the use of the C language in critical systems（第 3 版）。MISRA（2019）。 ↩ ↩2

4. C++ Exceptions: Pros and Cons。Nemanja Trifunovic（2009）。 ↩

5. P2544R0 C++ exceptions are becoming more and more problematic。Thomas Neumann（2022）。 ↩

6. 列挙型 std::error::Error。The Rust Team（2022 年閲覧）。 ↩

7. フィーチャー。The Cargo Book（2022 年閲覧）。 ↩

8. 条件付きコンパイル。The Rust Reference（2022 年閲覧）。 ↩

モジュールシステム

1994年の C++ の設計に関する講演で¹、この言語の発明者である Bjarne Stroustrup は次のように述べました。

私は、Simula² が提供していたような、プログラム編成のための支援を提供するツールが欲しかったのです。 Simula が提供していた、思考の助けと設計の助けです。 一方で、必要なときには BCPL³ や C のように本当に高速に動作するものが欲しかったのです。

「プログラム編成」とは、Stroustrup 博士が C++ のオブジェクト指向クラスのサポートを指していたものです。 編成のサポートは C++ の勝利の方程式の半分であり、もう半分はパフォーマンスでした。 保守性とドメイン抽象化の双方に適した方法でコードを効果的に編成することは非常に重要な問題であり、高性能アプリケーション向けにそれを解決したことで、C++ は数十年にわたって支配的な地位を占めることができました。

• Rust におけるクラスの代替: 高レベルデータに関するこれまでの議論では、トレイトと構造体がどのように相互作用し、継承ではなく合成によって振る舞いを定義するかを見ました。Rust の構造体と C++ のクラスは、プログラム編成の基本的な第一段階だと考えることができます。

では、なぜモジュールに関するセクションでこの話題を持ち出すのでしょうか⁴。特に、C++ は C++20 標準までモジュールシステムさえ持っていなかったにもかかわらずです（誕生からおよそ40年後のことです）。 それは、モジュールが、プログラム編成という時代を超えた問題に対する拡張された解決策だからです。

同じ90年代のインタビューで、Stroustrup は非常に実用主義的な洞察を示しています。

言語に関する私の主要な考え方は、言語とは、ある時点における一連の問題に対する誰かの応答だというものです。 つまり、言語は、それ自体が興味深い対象であるというよりも、問題を解決するために存在します。 私たちの問題、そしてそれらの問題に対する理解は、時間とともに自然に変化します。

そして、ある言語が、実際のコードに取り組む実際のプログラマーが直面する問題に対する優れた解決策であり続ける限り、その言語は生き続け、プログラマーのニーズを満たすために成長していくでしょう。

私たちはすでに、Rust の主要な価値が、予測可能なパフォーマンスを犠牲にすることなく、古くからあるメモリ安全性の問題を解決することだと確認しました（安全な並行性は「パフォーマンス」に含めて考えましょう）。 デバッグすべき未定義動作（UB）が少なくなることで、私たちはより野心的な高性能システムを迅速に構築できます。

構築する価値のあるほぼすべてのシステムは、最終的には規模と複雑さを増していきます。 顧客は新機能を要求し、開発チームは需要に応えるために新しいエンジニアを受け入れ、コードベースは拡大し始めます。 コード編成は「実際のコードに取り組む実際のプログラマー」にとって非常に根本的な問題であるため、それに対処する手段がなければ Rust は実用的ではなかったでしょう。

大規模なプロジェクトを整理され、まとまりのある状態に保つために、Rust はどのようなツールを提供してくれるのでしょうか。 大まかには、構成要素を次のように分解できます。

• アイテムは、ソースコード内のエクスポート可能な要素です。構造体、関数、定数などが含まれます。Rust におけるクラス風の抽象化である構造体は、間違いなく私たちの最も基本的な編成ツールです。プログラム編成階層の頂点です。

  • アイテムと見なされる言語構成要素の完全な一覧が利用できます⁵。技術的には、モジュールもアイテムです。しかし、現在のコード編成に関する議論の目的では、それらを分類上は別個のものとして扱います。

• モジュールは、関連するアイテムをまとまりのある単位にグループ化します。名前空間とよく似た形で、プロジェクト内のコードを整理するのに役立ちます。

  • 一部のプログラマーは、「1つのソースファイルにつき1つのモジュール」という慣習に従うことを好みます。しかし、その1対1の対応付けは完全に任意です。モジュールは論理的で階層的なグループ化です。ファイルシステムのレイアウトによって決まるものではありません。

• クレートは、関連する1つ以上のモジュールをライブラリまたはバイナリとしてグループ化します。プロジェクト間でコードを整理するのに役立ちます。ライブラリでは、可視性修飾子によって、モジュールがどのアイテムをエクスポートするかが決まります（例: クレートの公開 API）。

  • クレートは依存関係を持つこともでき、それら自体もクレートです（例: 内部で使用されるサードパーティライブラリ）。第2章の rcli ツールは、rc4 と clap という2つのライブラリクレート依存関係を持つバイナリクレートでした。

• システムは、相互接続されたコンポーネントから成る大規模なソフトウェアを指す一般的な用語です。これは、複数の Rust クレート、CFFI⁶ を介して相互運用する他のプログラミング言語で書かれたライブラリ、あるいは REST⁷ や gRPC⁸ のような構造化フォーマットを使用して通信するネットワーク化されたサブサービスでさえあり得ます。

モジュールで複雑性に対抗する

モジュールはこのセクションの焦点です。 コードを書くときには大きな「設計の助け」となり、読むときには「思考の助け」となります。 モジュールは、コードの機能的なまとまりを区分し、それらのインターフェースを定義します。 コード編成という時代を超えた必要性に対処する助けとなり、最終的には、複雑性を抑制する助けとなります。

私たちが構築するシステムの規模と機能が増すにつれて、それらは何らかの形の入り組みを少しずつ蓄積する傾向があります。 いったん複合化すると、複雑性はシステムの理解と変更を困難にします。 不要な複雑性は、障害やセキュリティ侵害の可能性を高めます。

蓄積された複雑性は、「技術的負債」と呼ばれることがあります。 金融上の負債と同じように、そこから抜け出すのは困難です。 したがって、単純さと保守性を考慮して設計することは、常に優先事項であるべきです。

さて、本書で構築するデータ構造ライブラリは、合計しても5,000行未満のコードになります。 大局的に見れば、これはごく小さなコードベースです。 しかし、私たちは最初から Rust のモジュールシステムを活用します。規模に依存しない利点が得られるからです。 それでは、モジュールがどのように機能するのか感触をつかみましょう。

ソースコードの編成

ファイルシステムのレイアウトからモジュールを推論する言語もあります。 Rust ではそうではありません。

Rust のモジュールは、個々のソースコードファイル（名前が .rs で終わるファイル）と緩やかな関係を持ちます。 モジュールは論理的なグループ化であるため、3つのモジュールとファイルの対応付け、すなわち多対一、多対多、一対一のいずれかを選択できます。 これらは排他的ではありません。単一のプロジェクトで、必要に応じて戦略を組み合わせることができます。

どの対応付けを選んだとしても、モジュールは常に木のような階層を形成します。 モジュールツリーにはルートが必要であり、通常は次のいずれかです。

• バイナリクレート（rcli など）の場合は main.rs
• ライブラリクレート（rc4 など）の場合は lib.rs 他のターゲット（テスト、ベンチマーク、例など）をビルドするクレートには、他のターゲット固有のルートがあります。

バイナリの場合、どの項目がどのモジュールで可視になるかは階層によって決まります。 これはライブラリの場合にも当てはまります。 さらに、ライブラリクレートは特定の項目やモジュールをエクスポートすることを選択できます。これにより公開 API が作成されます。

同じ単一の階層を維持する、3 つのモジュールとファイルの対応関係を見ていきましょう。

1. 複数のモジュール -> 1 つのソースファイル（m:1）

1 つのファイルにはネストされたモジュールを含めることができます。インラインモジュール定義の構文は次のとおりです。

mod my_module {
    // ここにモジュールの内容。ネストされた「サブモジュール」を含む可能性があります
}

この章で継続している OS の例を続けましょう。ただし、実際に起動可能なカーネルを作成するために必要な詳細については扱いません（このトピックは Philipp Oppermann の優れたチュートリアルシリーズ⁹で詳しく扱われています）。

新しいバイナリクレートを作成し、main.rs に次の内容を追加するとします。

mod kern {
    pub mod sched {
        // ここにスケジューリングのコード。`Proc` 構造体も含みます...

        /// プロセスの優先度を設定する
        pub fn set_priority(pid: usize, priority: usize) -> bool {
            // ここに実装...
        }
    }

    pub mod dma {
        // ここに Direct Memory Access（DMA）に関連するコード...
    }

    pub mod syscall {
        // ここにシステムコールに関連するコード...
    }
}

// サブモジュール経由のテストを示すためのダミー関数
fn private_helper() -> bool {
    true
}

#[cfg(test)]
mod tests {
    // 「ピア」モジュールから公開関数をインポート
    use super::kern::sched::set_priority;

    // 「親」モジュールからプライベート関数をインポート
    use super::private_helper;

    #[test]
    fn test_private_helper() {
        assert!(private_helper());
    }

    #[test]
    fn test_set_priority() {
        // ここにユニットテスト...
    }

    // ここにさらに個別のテスト...
}

どのような設計判断でも、“できる” と “すべき” は別物です。 OS や大規模なプロジェクトを、このように単一ファイル内で構成したいとはおそらく思わないでしょう。

しかし、多対一の対応関係は、モジュールが柔軟な概念であることを示しています。 この柔軟性のうち、実際に活用する可能性が高い側面の 1 つが、上記の末尾にあるような tests モジュールです。 これにより、ユニットテストを、テスト対象のコードの近く（同じファイル内）に置いておくことができます。

これは、プライベート関数をテストする場合に特に便利です。private_helper 関数が pub とマークされていないにもかかわらず、tests モジュールがその関数を使用できる点に注目してください。 その理由を理解するには、この単一ファイルが作成するモジュール階層を理解する必要があります。

暗黙的に、ファイル main.rs はそれ自体がモジュールです。 実際、これは階層のルートです。 つまり、mod tests は階層内のサブモジュールであり、トップレベルの main.rs モジュールの「子」を意味します。 これは、同じファイル内で宣言された「ピア」モジュール（kern）と同じレベルに位置します。

Rust では、サブモジュールは親のプライベート項目と公開項目の両方にアクセスできます。

• 例: tests は、use super::private_helper; によって、親からプライベート関数 private_helper をインポートできます。

プライベート項目は、ピア（kern のような階層内の同じレベル）や子（この例では tests には子サブモジュールがありません）からはアクセスできません。

• 例: tests は、kern からエクスポートされた公開項目にのみアクセスできます。use super::kern::sched::set_priority; によって、公開関数 set_priority をインポートします。

2. 複数のモジュール -> 複数のソースファイル（m:n）

mod kern の内容を、次のように kern.rs という名前のファイルへ移動できます。

pub mod sched {
    // ここにスケジューリングのコード。`Proc` 構造体も含みます...

    /// プロセスの優先度を設定する
    pub fn set_priority(pid: usize, priority: usize) -> bool {
        // ここに実装...
    }
}

pub mod dma {
    // ここに Direct Memory Access（DMA）に関連するコード...
}

pub mod syscall {
    // ここにシステムコールに関連するコード...
}

囲むための pub mod kern { ... } が不要になっていることに注意してください。これはファイル名によって暗黙的に示されます。 変更後のディレクトリの内容は次のようになります。

.
├── Cargo.toml
└── src
    ├── kern.rs
    └── main.rs

1 directory, 3 files

見てきたように、kern.rs はサブモジュールに対して、変更されていないインライン定義（例: pub mod sched { ... } など）を使用します。 したがって、上図の階層は維持されます。

main.rs が set_priority 関数をインポートするには、次を使用する必要があります。

mod kern;
use kern::sched::set_priority;

• mod kern; は、kern モジュールの内容が別ファイル、つまり kern.rs または kern/mod.rs に存在することを示します。

  • これらの「前方宣言」は通常、モジュールルートに配置されます。それが階層全体のルート（ここでは main.rs が該当）であっても、単にサブモジュールを含むモジュールであっても同様です。

• use kern::sched::set_priority; は、前のレイアウトで tests サブモジュールが行ったのと同じように、公開された sched サブモジュールから特定の関数をインポートします。

3. 1 つのモジュール -> 1 つのソースファイル（1:1）

より現実的なプロジェクトレイアウトでは、各モジュールを個別のファイルに配置することを選ぶかもしれません。 それでも、同じ階層は維持されます。

sched、dma、syscall のインラインモジュール定義の代わりに、各サブモジュールを次のように専用ファイルに配置できます。

.
├── kern
│   ├── dma.rs
│   ├── sched.rs
│   └── syscall.rs
├── kern.rs
└── main.rs

1 directory, 5 files

別ファイルからモジュールをインポートするとき、Rust は module_name.rs または module_name/mod.rs のどちらかを探します。 したがって、次のレイアウトは上記と等価であり、単に好みの問題です。

.
├── kern
│   ├── dma.rs
│   ├── mod.rs
│   ├── sched.rs
│   └── syscall.rs
└── main.rs

1 directory, 5 files

どちらの場合でも、3 つのサブモジュールについては、囲むためのインラインの pub mod mod_name { ... } を再び削除します。これはファイル名によって暗黙的に示されるためです。たとえば、sched.rs には現在、次の内容が含まれます。

// ここにスケジューリングのコード。`Proc` 構造体も含みます...

/// プロセスの優先度を設定する
pub fn set_priority(pid: usize, priority: usize) -> bool {
    // ここに実装...
}

kern.rs または kern/mod.rs（どちらのレイアウトを選ぶかによります）は、階層全体のルートである main.rs の下に位置するモジュールルートです（上図のとおり）。 この 1:1 レイアウトでは、このファイルが、その子サブモジュールを親である main.rs にどのように公開するかを制御できます。

簡単のため、最初の選択肢である kern.rs を採用したと仮定しましょう。 このファイルは、次のようにして sched サブモジュール全体を公開する（例: 再エクスポートする）ことを選択できます。

pub mod sched;