sasakiy84.net

セキュリティ・キャンプ 2026 ネクストに参加しました

36 min

セキュリティキャンプネクストに参加しました。 それぞれの講義で印象に残ったことをまとめます。

  • ハードウェア再現実装で学ぶアーキテクチャ解析
    • 先人の工夫に想いを馳せながら、ハードウェア記述言語とFPGAで遊びました
    • ハードとの対応をとりながらある程度の抽象化を施した記法や、ハードウェアでコードが実行される方法は、これまで触ってきたどの言語とも異なるもので、ハードウェア記述言語には非常に興味を惹かれました
  • 低レベル MN-Core グラフコンパイラ自作入門
    • MN-Core というアクセラレーターのアーキテクチャのグラフコンパイラを作るためにアセンブリを書きました
    • 普段使っている汎用的なアーキテクチャとは異なる尖ったアーキテクチャを学ぶことは、翻って汎用型のメリット、デメリット、必然的な設計、意外と改善の余地がある設計を際立たせ、汎用型に対する解像度が上がりました
  • C++ の進化と安全なライブラリ設計
    • C++ の変遷と最新の記法を学びました
    • 言語の設計思想や歴史などの背景事情に思いを馳せながら、普段使っている言語をもう一度観察し、他の言語に入っている機能がなぜその言語では他の書き味で使われているのかや、なぜ他の言語では入っている（いない）機能がその言語には含まれている（いない）のかを考えることで、その言語への解像度を上げることができました
  • TCP/IPプロトコルスタック自作入門
    • TCP/IP を OS で動かすためのプロトコルスタックを実装しました
    • なぜそのようになっているのか、などの疑問が実際のコードをみると湧いてくるので、理解が曖昧だった部分を明確にすることができました
  • サイバーセキュリティに関する法規って本当に必要？ | 自動車・製品セキュリティを例に、法規の重要性と限界を考える
    • 作成したものを販売するときに、安全だということを第三者にどのように説明するのか、という問いを扱いました
    • 信頼された有識者によって策定された満たすべき要件を定め、テストなどにより一定の能力があることが認められた認証機関を信頼して、その認証機関が審査した製品は信頼できるとするレピュテーションチェーンのモデルを学びました

なお、応募課題はこちらにあります。

また、他の方の応募課題は以下から閲覧できます。

以下は、あまりきちんと読むことを想定していない長文です。

N1・N5『ハードウェア再現実装で学ぶアーキテクチャ解析』

本講義では、コンピュータシステムをFPGAボードで実際に再現していただきます。

最初のステップとして、コンピュータシステムをソフトウェアモデルとして再現します。システム利用者向けの仕様情報を元にアーキテクチャの詳細を推測し同等機能を実現することで、システムの設計制約や先人の設計意図に思いを馳せ技術の謎を解き明かします。

次のステップでは、再現したソフトウェアモデルをリファレンスとして、コンピュータシステムをFPGAに実装します。モデルから論理回路アーキテクチャへ落とし込む過程において未知なる部分を補完することで、先人との仮想的なシンクロを楽しむことができます。

講義での試行錯誤を通じて突破力を発揮していただき、これまでのコンピュータシステムや解析技術に対する理解を深めるとともに、これからの技術発展にひらめきを得られるようになることを目指します。

（注釈）受講者には事前学習として、使用するFPGAボードの機能確認および実装対象の仕様把握を依頼します。

講義の前後で、自身の知識がもっとも増えた講義でした。講義のタイトル通り、既存のシステムのアーキテクチャをハードウェアで再現するのですが、私自身は L チカをしたことがないようなレベルのハードウェア未経験者だったので、予習課題から当日の講義まで含めて非常に学ぶことが多かったです。事前学習では、FPGAの動作確認やハードウェア記述言語の環境構築、対象システムの仕様把握などをしました。とくに、ハードウェア記述言語には非常に興味を惹かれました。ハードとの対応をとりながらある程度の抽象化を施した記法や、コンパイルした結果が最終的に回路になるという挙動は、これまで触ってきたどの言語とも異なるもので、プログラミング言語好きとして学習し甲斐がありそうです。ちなみに、私はこの講義で初めて FPGA という単語に出会ったのですが、夢があるハードウェアですね。加えて、分析するアーキテクチャも私自身には馴染みのないもので、開発者の工夫が随所に見られました。

当日の講義ではハードウェアである FPGA ボードで実装したシステムを実行をしました。ここで、ハードウェアの洗礼をうけ、動くはずのコードが動かないという事態に遭遇しました。いろいろ条件を変えて試したりしたのですが、時間切れで解決できませんでした。心残りです。

既存のシステムを分析するソフトウェア考古学という分野があります。私が専攻している図書館情報学の分野では、実行方法が失われたメディアに記録された情報を取得したいというケースは十分に想定されるものであり、その観点からもどのように既存システムを分析するかという観点で役にたつものでした。

N2『低レベル MN-Core グラフコンパイラ自作入門』

近年の深層学習をはじめとする科学技術計算では膨大な量の計算を高速に行う必要があり、GPUなどの並列演算器が活躍しています。
これは一つ一つの計算コアは単純にする代わりに多数のコアを持つことで、トータルの計算能力を向上させるものです。
深層学習の世界ではそれでもなお膨大な計算を行う必要があるため、さらにタスクに特化した設計で計算効率を改善させたアクセラレーターが多数提案されています。
本講義では、そのようなアクセラレーターの一つであるMN-Coreに焦点を当て、学習用の簡易グラフコンパイラ（MLコンパイラ）を受講生全員で協力して改造し、MN-Core上でMNISTデータセットのトレーニングができるようにしてもらいます。

MN-Coreは深層学習での計算を念頭に厳選されたシンプルな命令セットを持ち、仕様やエミュレーターがオープンアクセスで公開されている国産アクセラレーターです。MN-Coreを使用したスーパーコンピューターMN-3は省電力性能ランキングGreen500で世界1位を3度獲得しており、Preferred Networks社内の実ワークロードや社外向け製品でのバックエンドとしても運用されています。
MN-Coreの低級プログラミングを通じ、CPUやGPUとは更に違う、特色ある設計思想のアーキテクチャを理解し、計算機の設計法やプログラミング手法としてのグラフコンパイラについて考える機会を提供します。

（注釈）この講義では、キャンプ本期間前に事前課題を課します。あまり時間をかけられなくても講義は問題なく進められるように設計されていますが、講義を通じてより多くのものを得たい場合、選考通過発表後からキャンプ期間までの間のスケジュールを詰め込みすぎないことを、弱くおすすめします

PFN が開発している MN-Core というアクセラレーターのアーキテクチャのグラフコンパイラを作ろうというものです。事前学習では MN-Core の仕様を把握するための教材で、コードゴルフコンテストの問題を解きました。要するに MN-Core アーキテクチャのアセンブリを書くのですが、機械学習向けに relu 命令が用意されていたり、データをメモリにロードしたあとはメモリに一定期間アクセスできないなどの制約を満たすために明示的に nop を挿入したりと、MN-Core の特徴を存分に味わえる内容となっています。

普段使っている汎用的なアーキテクチャとは異なる尖ったアーキテクチャを学ぶことは、翻って汎用型のメリット、デメリット、必然的な設計、意外と改善の余地がある設計を際立たせ、汎用型に対する解像度が上がると考えています。その意味で、MN-Core という特定のアーキテクチャを対象にした講義ではありつつ、それにとどまらない汎用的な知識を得ることができました。

N3『C++ の進化と安全なライブラリ設計』

メモリ安全性への関心が高まるなか、C++の設計や使い方が改めて問い直されています。C++では std::expected（C++23）に代表されるように、ライブラリレベルで他言語の発想を取り入れながら、安全性や使いやすさを高める試みが進んでいます。しかし言語レベルでの根本的な解決にはなお課題があり、API 設計の工夫で補う発想がいっそう重要になっています。

本講義では、C++11 から C++23 までの機能の変遷を踏まえつつ、安全で使いやすい C++ ライブラリの設計を学びます。モダン C++ の機能をどのように活用すれば、利用者にとってわかりやすく、誤用されにくい API を設計できるのかを、具体的な実装や演習を通して身につけます。

【チャレンジ】
講義内の演習に加え、希望者はオリジナルのC++ライブラリ開発にも取り組めます。
受講者向けDiscordでは、キャンプ前後を通じて講師に相談できます。サポート期間（２～3 か月）を通して設計と実装を磨き、公開可能な OSS として形にすることを目指します。

【想定レベル】
C++で標準ライブラリ（std::vectorなど）を使った簡単なプログラムを書いたことがある方を対象とします。
テンプレートやムーブセマンティクスなど、高度な言語仕様の知識は必須ではありません。必要な知識については講義や事前学習でフォローします。

C++ は非常に歴史ある言語で、その分だけ過去の資産（あるいは負債）が積み上がっています。それらの過去に積み上げたものを活用しつつ、より安全に便利に C++ を書きたいというモチベーションが当然あるわけです（安全に書きたくないから C++ を使うという主張もありますが）。そして、その安全な書き方においても、高速に動作してほしいです。これらの制約を満たしながら、新しい言語機能を追加していくのは非常に難しいことで、筋の悪い機能を入れてしまったり、互換性を保つために理想的な記法が使えなかったりすることもあるわけです。そのような背景事情に思いを馳せながら、普段使っている言語をもう一度観察し、他の言語に入っている機能がなぜその言語では他の書き味で使われているのかや、なぜ他の言語では入っている（いない）機能がその言語には含まれている（いない）のかを考えることで、その言語への解像度を上げることができるでしょう。そのことを再認識できる講義でした。

N4『TCP/IPプロトコルスタック自作入門』

この講義では、インターネットをはじめとする現在のコンピュータネットワークを支えている基盤技術「TCP/IP」のプロトコルスタックをフルスクラッチで実装し、実際のOSに搭載してネットワーク機能を持たせる演習を行います。

講師が開発している教育用のプロトコルスタック「microps」を教材に、Ethernetフレームを組み立てて送受信するところから ARP、IP、ICMP、UDP、TCP などのプロトコルを処理するプログラムを、全て自分の手で作り上げてもらいます。

なお、講義時間が限られているためプロトコルスタックの基本的な実装は事前学習の期間（約1ヶ月）で済ませてもらいます。各自で事前学習を進めてもらうにあたり、解説資料を配布するとともに、ミーティングの機会を設けてしっかりフォローアップしますので安心してください。

講義時間では、あらかじめ開発を進めておいてもらったプロトコルスタックを、教育用OSの「xv6」に搭載して実際にTCP/IPでの通信を実現することを目指します。具体的には、次のような作業を行うことになります。

  • xv6 (github)

  • デバイスドライバの実装

  • プロトコルスタックの移植（プラットフォーム依存の処理の実装）

  • ソケット関連システムコールとユーザライブラリの実装

この講義を通じてTCP/IPへの理解を深めるとともに、パケットやプロトコル処理の楽しさを知ってもらえたら嬉しいです。

事前学習も当日も非常に大量のコードを扱う講義でした。以下に事前学習の進捗報告で送っていたメモを載せます。すでに掲載してくださっているコードを移せばいいので、実装で詰まるということはないです。しかし、なぜそのようになっているのか、などの疑問が実際のコードをみると湧いてくるので、理解が曖昧だった部分を明確にすることができました。 また、TCP/IP の仕様の説明や理論的な解説をする文書はありますし、syscall やプロセスなどの説明をするOSの教科書もありますが、その中間を埋める教材はないため、その点でも面白い領域の講義でした。 ちなみに xv6 に移植した動くはずのコードが動かないバグが残っているんですが、どうしよう、、、。

なお、資料は以下に公開されています。

N4 事前学習の進捗報告

7/6

今週までの進捗です。また、本日は予定があり欠席します。

[Keep]

[Problem]

  • デバイス管理などで配列や辞書型ではなく、linked list を使う理由がわからなかったです。linked list の利点として要素の挿入がしやすいというのがあると思いますが、デバイスを頻繁に追加したりするわけではないので、なんらかの理由があれば知りたいです（C言語をほぼ初めて書くんですが、C言語の流儀だったりするんでしょうか？）

[Try]

  • ch10-ch12 くらいまで進めたいです

7/13

今週までの進捗です。

[Keep]

  • ch 10 まで進めました
  • https://www.rfc-editor.org/info/rfc791/#section-3.2 の Identification の話
    • It seems then that a sending protocol module needs to keep a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet.
    • 疑問が２つあったので調査
    • １つめはこれはどのような表のことか。プロトコル、src, dst のタプルに対して、最後に使ったIDとその時間を記録して、新しいIDを使ったら更新していくような表？それだとインターネット上で昔のパケットが漂流している可能性を否定できない。というか、そもそも送信したパケットのTTLが切れているかどうかはホスト側からは確認できないのでは？
      • と思ったけど、RFC 791 の時点では、TTL は実際の秒数として仮定する考え方があったらしい
      • the field must be decremented by 1. The time is measured in units of seconds (i.e. the value 1 means one second). Thus, the maximum time to live is 255 seconds or 4.25 minutes
    • 2つめは、65,536の空間は条件次第ですぐに埋まってしまいそう。と思ったら、まさにそういう議論があった。 https://www.rfc-editor.org/rfc/rfc6864.html
      • 簡単にいうと、IDの話を厳密に守っていたら6.4Mbpsしかでないから、フラグメントしていないときはIDは気にしなくていいということ
  • https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
  • ethernet の MTU は一般的に「1500」である理由

[Problem]

  • Identification の話の table は、プロトコル、src, dst のタプルに対して、最後に使ったIDとその時間を記録して、新しいIDを使ったら更新していくような表というイメージで合っているか
  • ethernet の MTU が 1500 である理由として、当時の上の層が求める値が 500 to 2000 bytes くらいだったからというのが、当時の状況がよくわかっていないのであまりイメージができない。たとえば、IP のようなプロトコルがたくさんあって、下の層のMTUは750bytesとする、みたいなことを別々に決めていたのか。そうだとしたら、なぜ2000bytesではなく1500にしたのか

[Try]

  • ch15-ch17 くらいまで進めたいです

7/20

今週までの進捗です。

[Keep]

  • ch 14 まで進めました
  • ハードウェアとプロトコルのタイプと Opcode 空間が 2bytes あることについて
    • https://www.rfc-editor.org/info/rfc826/
    • Protocol Type が2バイトなのは、既存の16ビットのEtherTypeをそのまま再利用したため
    • ハードウェアフィールドについて、this will require another value as will other future hardware mediums that wish to use this protocol.
    • プロトコルフィールドについて、 It is hoped that we will never see 32768 protocols, but Murphy made some laws which don’t allow us to make this assumption.
    • op code について、The opcode is to determine if this is a request (which may cause a reply) or a reply to a previous request. 16 bits for this is overkill, but a flag (field) is needed.
      • 16bit にする理由にはなっていないが、アラインメントの問題な気がする
    • Ethernetのデータ領域には46バイトという最小長があり、不足分はパディングされるので、28バイトのARP のパケットを切り詰める必要はない
      • でも、Ethernet 以外のことも想定していた
  • arp spoofing は ipv6 の NDP で解決されているのか？
  • ch14 の ARP の実装について、cache のエントリー INCOMPLETE のときに、常にまたresolveしようとしてarp_requestを送るなら、短期間の間に何度も resolve を試みて arp request を送りすぎて帯域を無駄遣いしてしまう可能性がありそう

[Problem]

[Try]

  • ch19 から ch21 くらいまで進めたいです

7/27

[Keep]

  • ch19 まですすめました
  • UDPのチェックサムを計算するときの擬似ヘッダは、階層モデルの限界？
  • 既に説明してあるとおり、 IP によるパケット分割が発生するとパケットの断片が 1 つでも消失した場合に残りの断片が全てゴミとなり通信効率が悪くなってしまいます。実際の通信ではパケット分割が発生しないように、アプリケーションが送信データのサイズを調整することが望ましいです。

[Problem]

  • 一つのルーティングテーブルに登録されるエントリの数って、実際のルーターだとどれくらいなのだろう
    • 業務で使うような規模で。たとえばデータセンターとか？

[Try]

  • ch24-26 くらいまですすめたい

8/3

[Keep]

  • ch25 まですすめました
  • シーケンス番号をバイトストリームの位置ではなく、セグメントの番号のことだと思ってた
  • TCPの状態遷移図からは TIME_WAIT が必要な理由がわからなかった
    • たとえば、CLOSING で、ACK 受信したら、そのままCLOSED になればよいのではないか、と考えた
    • 調べると、相手側に ACK が届いていなくて、相手が FIN を再送する可能性があるので、そのときに ACK を再送するために TIME_WAIT がある
    • FIN_WAIT_2 経由のときも同様

[Problem]

  • とくになし

[Try]

  • ch30 まで

8/10

今週の進捗です。

[Keep]

  • ch30 まですすめました
  • ch28 で接続中に不正な SYN が送られてきたときにリセットする挙動を実装した
    • 悪意のある人がこれを使って強制切断させまくって、そのネットワーク内の機器を機能不全にする、とかも可能？
    • 現在のセグメントの位置を総当たりで当てられれば、blind reset攻撃に悪用可能なため、RFC 5961ではChallenge ACKを使う対策が追加された。
    • https://www.rfc-editor.org/rfc/rfc9293.html#section-3.10.7.4-2.4.2.3
      • TCP implementations MUST drop the unacceptable segment and stop processing further.

[Problem]

  • とくになし

[Try]

  • とくになし

N6『サイバーセキュリティに関する法規って本当に必要？ | 自動車・製品セキュリティを例に、法規の重要性と限界を考える』

セキュリティの法律と聞くと、どういったものが思い浮かびますでしょうか。多くの人は、個人情報保護法や、サイバーセキュリティ基本法等、直接自身に関係するものが思いつくと思います。製品を販売するにあたっても、同様に電波法等の必要な認証取得が必要になってきます。実はこうした製品の認証取得の要件にもサイバーセキュリティに関する対策を実装することが定められており、企業は都度対応に追われているのが現状です。しかしながら、現場目線では法規や認証に書かれているサイバーセキュリティ対策は抽象度が高く、理想論のようなものとして扱われがちなものとなっており、現実的に何をしたら良いのか分かりづらいという課題があります。

本講義では、自動車やIoT製品を例として、法規・規格が策定される流れ、製品の認証取得に必要な手順などを解説し、世の中のサイバーセキュリティの法規の枠組みを理解し、法規の限界を考えます。また、ワークを通じて実際に法律や規格を読み解き、法規対応・認証取得の流れを理解いただくことを目指します。

ネクストの講義は幅が広い、と言われる理由の一つです（他の講義でも必要な事項であれば法律について触れているとは思いますが）。この講義では、作成したものを販売するときに、安全だということを第三者にどのように説明するのか、という問いを扱っています。全てを自分で確かめるわけにもいかないし、自分で確かめたとしてもそれが正しいといえる場合が非常に少ないという、ままならないこの現実世界においては、この問いにレピュテーションのチェーンを使って解としています。つまり、信頼された有識者によって策定された満たすべき要件を定め、テストなどにより一定の能力があることが認められた認証機関を信頼して、その認証機関が審査した製品は信頼できるとするモデルです。その中で、満たすべき要件とされているものは法令であったり、標準であったり、規格であったりします。しかし、実際にその文面を見てみると、具体的に何をすればいいのかがわからないような抽象的な書き方をしていることも多いです。その場合、その要件を満たすためには何をすればいいかを調査し、関係者間で合意していく必要があります。 予習課題では本の概要把握と、なんらかの要件を選んで分析するという課題がありました。具体的な要件を設定することで、その要件が対象とする分野における法律側の対応がどのようになっているかが理解できましたし、それをさらに抽象化した大まかな枠組みは、他の分野で同じようなことをするときに役立つと思います。

その他

  • 授業のときも、あるいは休憩時や食事のときも、生徒と講師の距離が近く、気軽に質問ができて満足でした
  • 最終日に企業交流パートがありました。ここでも、企業の方との距離が近く、聞きたいことを聞くために十分な時間がとれたので満足です
  • 技術の話を存分に聞ける、話せる空間は良いもので、刺激をもらいました