Save 37% off PRO during our Black Friday Sale! »

IoT_device_development_with_safe_language

 IoT_device_development_with_safe_language

6bb0559d2066b868dab09e435f488c6c?s=128

tomoyuki-nakabayashi

March 16, 2019
Tweet

Transcript

  1. 安全性の高いプログラミング言語での IoTデバイス開発 中林 智之(connectFree株式会社) @LDScell 2019/03/16 IoTSecJP東京 Version5.0 ※発表資料は発表終了後に公開します 1

  2. 70% ヒント:2019年2月 Microsoft 突然ですが、何の数字でしょう? 2

  3. マイクロソフトのセキュリティバグのうち 70%がメモリ安全性の問題 > 原因は、WindowsのほとんどがC/C++という メモリ安全でない言語で書かれているため 3 Microsoft: 70 percent of

    all security bugs are memory safety issues
  4. つまり・・・ C/C++は あぶない! 4

  5. 発表の概要 • C/C++問題点 • C/C++代替候補言語の紹介 • Rustの紹介 – 言語概要 –

    安全性のヒミツ – 組込みRustの状況 安全性の高いプログラミング言語を検討しよう! マイコン搭載のIoTデバイスでも 5
  6. 諸注意 • 以下の意図はありません –C/C++の完全否定 –C/C++は古臭くてダメ! –C/C++を一切使用するな! –全てをRustで書くべき! • よりセキュアなプログラミングを行うための選 択肢を提供したい

    6
  7. 自己紹介 • 中林智之 (connectFree株式会社 組込みプログラマ) • Twitter: @LDScell • GitHub:

    tomoyuki-nakabayashi • ブログ: 低レイヤ強くなりたい組込み屋さんのブログ 7
  8. 本発表でのIoT/組込みデバイスの定義 • マイクロコントローラ搭載デバイス – ~100MHz程度のプロセッサ (Cortex-M相当) – ~1MB程度のROM (Flash) –

    ~数百キロ程度のRAM – OSなし or RTOS (Real Time Operating System) 8
  9. 背景 • 組込みデバイスでのセキュリティが重要化 – IoTでは組込みデバイスもネットワーク接続 – 前ページで紹介したようなマイコンが数億個も… • セキュリティ設計に脆弱性がなくても –実装レベルでバグを作ると被害が甚大

    • C/C++ (特にCの機能) は危険! – 型安全性、メモリ安全性、スレッド安全性を保証しない 9
  10. メモリ安全性 • メモリ安全である、とは次のような現象が発生し ないこと – バッファオーバーフロー / バッファオーバーラン – Nullポインタ参照外し

    – メモリ解放後の領域へのアクセス – 初期化していないメモリの利用 – 不正な解放(2重解放 / 未確保領域の解放) C/C++はメモリ安全な言語ではない 残念ながら… 10
  11. Heartbleed • 2014年に話題になったOpenSSLのバグ > 信頼された認証局から証明書が発行されている Webサーバの17%(50万台)で、サーバの秘密 鍵や利用者のセッションクッキー、パスワードを盗 み出すことが可能な状態だった • 設計レベルでの脆弱性はなし

    • メモリ操作の実装バグ (バッファオーバーラン) ☞ポイント 11
  12. プログラミング言語での対策 • 問題あるプログラム実装に対して • バグったままプログラム動作が継続 – 情報漏洩が発生する最悪の状況 • プログラムがクラッシュする –

    脅威レベルはDoS攻撃対象まで下がる • コンパイルエラーになる – リリース前に問題に対処 可能な限り ここで 対処したい C/C++ 12
  13. そうは言うけど 組込みって C/C++しか 選択肢ないでしょ? 13

  14. • IoTデバイス開発でもプログラミング言語が選べる 時代になりつつある • コンパイラ技術が発展 • LLVMが登場 – GCCに匹敵するコンパイラ実装の敷居が下がった 朗報

    14
  15. LLVM ↑フロントエンドを 頑張れば、新しいプログラミング言語が作れる 15 Compiler Infrastructure LLVM 中 間 表

    現 最 適 化 機 械 語 生 成 フ ロ ン ト エ ン ド
  16. 候補言語 • LLVMをバックエンドに持つ言語(OSS) 16

  17. Go 主な支援企業 Google 目的 スクリプト言語の生産性と コンパイル言語の速度 言語仕様の複雑さ シンプル メモリ管理 ガベージコレクション(GC)

    その他 マイコンで使えるTinyGo 17
  18. 主な支援企業 Mozilla 目的 速度、並行性、安全性 言語仕様の複雑さ 難しい メモリ管理 多くのことをコンパイラが検証 その他 型安全、メモリ安全、スレッド

    安全で、資源効率はCに匹敵 Rust 18
  19. どこで使われているの? • Firefox CSSエンジンStylo • Google Chrome OS VMM crosvm

    • AWS VMM firecracker • Facebook Mononoke / MIRAI • Microsoft IoT Security Proxy Edgelet 安全性と性能が求められる領域 19
  20. Rust安全性の ヒ・ミ・ツ♡ 20

  21. コンパイラが 鬼!!! 悪いコードはいねぇがぁ~ 21

  22. > Rustを使い始めてわかったのは、C/C++では 長い間かけてゆっくり学んでいたような「良い書き 方」を学ばないことには、 Rustではプログラムをコ ンパイルすることすらできない、ということだ。 By Mitchell Nordine プログラミングRustより

    22
  23. Rustの安全性 • コンパイラを鬼コーチにする言語仕様 – 所有権 – 借用 – ライフタイム •

    ランタイムチェック – 配列の境界検証 23 参考:RustはHeartbleedを防げたのか?
  24. ここから5分ほど 少し細かい言語仕様のお話です 24

  25. 所有権 • C言語では、複数の場所から変数を書き換える ことが可能 • Cではvalueも*aliasも同じ値を変更でき、バグ の温床に int32_t value =

    42; int32_t *alias = &value; value += 1; *alias += 1; 25
  26. 所有権 • C言語では、複数の場所から変数を書き換える ことが可能 • Cではvalueも*aliasも同じ値を変更でき、バグ の温床に int32_t value =

    42; int32_t *alias = &value; value += 1; *alias += 1; 26
  27. 所有権 • 全ての値は、値を変更できる唯一の所有者が存在 • 動的確保したメモリでも、マルチスレッドでも同様 • 同時に複数箇所から値を書き換えるコードはコンパ イルエラーとなり、データ競合を防ぐ let mut

    value = 42; let mut alias = &mut value; value += 1; // compile error! *alias += 1; 27
  28. 所有権 • 全ての値は、値を変更できる唯一の所有者が存在 • 動的確保したメモリでも、マルチスレッドでも同様 • 同時に複数箇所から値を書き換えるコードはコンパ イルエラーとなり、データ競合を防ぐ let mut

    value = 42; let mut alias = &mut value; value += 1; // compile error! *alias += 1; 所有権が aliasに移動 valueは値を 変更できない 28
  29. 借用 • 所有権は貸すことができる。これを借用と呼ぶ。 • 借用は下記のどちらか一方だけの状態を持つ – 唯一の可変参照を持つ – 複数の不変参照を持つ •

    誰かが書き換える可能性がある変数は、他の誰 も読むことすらできない • 誰も書き換えない変数は、複数の場所から読む ことができる 29
  30. ライフタイム • 全ての変数には生存期間がある • 生存期間を終えた値(資源)は破棄される • 動的確保したメモリも、生存期間を終えると、自 動的に解放される(メモリリークなし) • 生存期間を終えた変数へのアクセスはコンパイル

    エラー(解放した領域へのアクセスができない) { let heap = Box::new(1); } // release allocated memory here 30
  31. なぜ今、Rustで組込み? • 安全性が高い – マイコンがネットワーク接続 – IoTデバイスは認証情報を取り扱う • 資源効率が高い –

    高速 – メモリ占有量が少ない • 利用できる基盤が整ってきた 31
  32. 組込みRust • アーキテクチャサポート – x86 / ARM (aarch64, v6 ,v7)

    / RISC-Vなど • 主要なSoC/マイコン/ボードにライブラリ提供 – Cortex-A/M/R, MSP430, RISC-V, Linux 32
  33. でもドキュメント 英語なんでしょ? 33

  34. 和訳プロジェクト進行中! • The Embedded Rust Book (和訳済み) – https://tomoyuki- nakabayashi.github.io/book/

    • Discovery (和訳進行中) – https://tomoyuki- nakabayashi.github.io/discovery/ 34
  35. 御託はいいから 動く物を見せろ! 35

  36. デモ:IPv6 TCPエコーサーバ • ソフトウェア – C言語のRTOS (Zephyr)上で動くアプリケーション をRustで実装 – C言語の資産を活かしつつ、新規実装分をRustで

    • ハードウェア – nRF52840 USB Dongle (1100円) • 64MHz Cortex-M4F / ROM 1MB / RAM 256KB – SPI Ethernet MACコントローラ (300円) 36
  37. 組込みRustの課題 • C言語とのギャップが大きく、学習コストが高い – シンタックス – セマンティクス • エコシステム –

    商用レベルのRTOSがない – C/C++ほど資産がない • C/C++の資産を使いながら、新規開発部分や 最重要部分をRustで実装する 37
  38. まとめ • C/C++は危険! • 組込み開発でも言語が選べる時代に • 現状、Rustが有力候補 • Rustは安全性が高い –

    コンパイラが鬼強い – 型システム、所有権、借用ライフタイム • 導入可能なところから使っていこう! 38
  39. 39 最後にもう1つだけ プログラミング言語を紹介させてください!

  40. WARNING!! A NEW PROGRAMMING LANGUAGE ZEN IS APPROACHING FAST 40

  41. Zen 開発企業 connectFree (2015~) コンセプト 善:善いコードを書く 全:全体を考えたコードを書く 漸:少しずつコードを書く 複雑さ Rust→安全なC++

    Zen →安全なC その他 C言語のヘッダを直接include可能 C言語より低レベルの記述が可能 41
  42. 2019年4月末 公開予定 42 Twitter:JoyofZen