STM32MP2 を遊びながら学ぶ

2026/11/09 4:04

STM32MP2 を遊びながら学ぶ

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

最も重要な示唆は、STM32MP257F マイコン制御装置の TrustZone 隔離機能内で発見された重大なセキュリティ脆弱性です。研究チームは、「ゼロ化攻撃(zeroing attacks)」、すなわち特定のメモリアドレスにゼロを書き込むことでセキュリティ境界を迂回し、悪意のある外部ペイロードが必要とせずに不正な権限昇格やコード実行が可能になることを確認しました。この欠陥は、すでに ST PSIRT による正式なセキュリティ警報の発表およびハードウェアエラタアップデートにつながりました。セキュリティリスクに加え、同プロジェクトは複雑なベンダー SDK を使用せず、標準のアップストリームツールとオンチップ SRAM のみを用いてバアメタル上で安全な Linux の動作を実証することに成功しました。構築過程では、クロックジャッターにより引き起こされた重要な PCIe 接続問題を解消し、不安定な内部クロックから安定した外部クリスタルへ切り替えることで高データ転送速度を実現しました。低コスト評価ボード上でこのハイパフォーマンスアーキテクチャを検証する中で得られた知見は、現在の代替製品である STM32H7 シリーズなどがピン数やルーティングについて不必要な複雑性に苦しんでいることを示唆しています。今後の作業では、FPGA と PCIe スタックの統合ならび、バックアップ SRAM に新たに特定されたメモリアルートを通じた潜在的なエクスプロイトの検証を調査することを目指します。

本文

スクラッチ音(Record Scratch):STM32MP2 と FPGA をつなぐ挑戦と重大なセキュリティバグの発見

1. プロローグ:謝罪と背景

この投稿は長期にわたって作成され、STMicroelectronics (ST) の公式アドバイザリー公開を待たなければ発表できませんでした。長年の読者に向けて、STM32 と FPGA を組み合わせた高性能な Ethernet(約 1 Gbps)システム開発の経緯と、その過程で発見した重大なセキュリティ問題を報告します。

2. 理想の MCU への求めと現実は

既存の STM32H7 シリーズには以下の課題がありました:

  • ピン数の多さ: FMC インターフェースをフル活用すると 30 ピン以上必要で、パッケージ上にばら撒かれているため実装が困難。
  • コストと配線: 低コストなバッチファブでの実装は事実上不可能(FMC の制約)。0.8mm パッケージ製品は最大周波数(480 MHz)が低く、本質的な解決になっていない。
  • PCIe の欠如: PCIe を搭載した Cortex-M は理想だが、周辺ライブラリとの互換性や暗号機能のロックアウト問題があるため採用できない。

3. 突破口:STM32MP2 と Linux

STM32MP2 シリーズ(デュアルコア Cortex-A35 + M33/M0+)が新たな選択肢となりました:

  • 高機能: 5 Gbps SERDES、PCIe Gen1/2、USB 3.0 対応。AES-GCM、TRNG IP が完備。
  • 利点: ARM64 エコシステムとの親和性が高く、学習曲線が緩やか。
  • 懸念点: Linux BSP(u-boot, TrustZone)等非必要機能が含まれており、「シンプルで RTOS 対応」な MCU を求めたかった点との乖離。

実験目標

  • メーカー SDK/HAL を一切使用せず、アームツールチェーンだけで構築。
  • A35/M33 コアのみを動作させ、外部 DDR を不使用(オンチップ SRAM 活用)。
  • TrustZone/u-boot を排除し、EL3 レベルからイベントループを実行する「裸金属」環境を構築。
  • この条件下で PCIe と FPGA をつなぐ。

4. M33 コアの起動 (Bring-up)

M33 補助コアでの単独動作確認とフラッシュ起動への挑戦:

  1. LED ブリンク: JTAG を介した通信とレジスタ操作に成功。
  2. フラッシュ起動: 内部 SRAM の複数マッピングやブート ROM の制限を乗り越え、FSBL(初期段階ブートローダ)を自前で構築。不揮発性メモリからの自律起動を実現。

FSBL イメージの配置注意点

  • RETRAM (0x0e08_0000): コードイメージ配置。
  • D サイドバスのエイリアス (0x3008_0000): スタックと初期変数配置。
  • メモリの重複回避: コード
    0x0e08_xxxx
    とデータ
    0x3008_xxxx
    は物理的に重ならないようリンカスクリプトで管理必須。

M33-TD モードでの設定項目

SoC 設定にはカスタムアセンブリを避け、C/C++ で実装可能な範囲で行います:

  • 電圧監視: VDDIO1〜4 の VDDIO モニタ有効化(I/O 利用の前提)。
  • メモリアクセス許可:
    RISAB SECCFGR
    レジスタ設定により、EL3 セキュアモードで SRAM1/2 および VDERAM にアクセス可能にする。
  • クロックツリー: M33 の I/D L1 キャッシュ制御や PLL 設定。

5. A35 コアの起動と初期化

PCIe が動作するよう A35 メインコアを起動:

  • 起動手順: CPU の状態確認 (DSTATE) → SEV イベントで目覚ましさせる → リセット → HOLD_BOOT 状態待ち → 解放。
  • イメージ配置: フラッシュ上の FSBL-A(プライマリー
    0x0008_0000
    )をアセンブリ言語で初期化。M33 から SRAM にダンプせず、ブート ROM が直接読み取る構造を採用。
  • 起動時の必須タスク:
    • スタックポインタ初期化と未定義レジスタのクリア。
    • 例外ハンドラテーブル(VBAR_EL3)への指向。
    • キャッシュ一貫性の有効化 (
      CPUECTLR_EL1
      )。
  • MMU とページテーブル:
    • 3 レベルのページテーブル作成(オンチップ SRAM、PCIe BAR、周辺機器をマッピング)。
    • ブート ROM リージョンは意図的にマップ外に置く(ランダム読み取り防止)。
    • MMU を NX およびキャッシュ属性制御用にのみ活用。

6. システム性能と DDR の見送り

  • ストレージ: フラッシュなし。コードとデータを高速なオンチップ SRAM (808 KB) に収めるか、低速な XIP 外部 SPI フラッシュを使用。
  • 処理性能: 1.5 GHz デュアルコア A35 は M7 の約 4 倍の速度だが、IPC(命令実行効率)は低い。ITCM/DTCM の欠如により L1 キャッシュミス時はシングルサイクルにならないのが惜しい。
  • DDR不使用的理由: DDR コントローラと巨大な PCB デザイン、高い消費電力に対し、PCIe を導入してメモリバスを置き換えるメリットが相殺されてしまうため。

7. PCIe の立ち上げとバグの発見

ハードウェア接続

  • Mini PCIe スロットから M.2 NVMe SSD や FPGA モジュールへのインターフェースを試行。
  • システム設定:COMBOPHY/RCC 有効化 → 外部参照クロック (100 MHz) または内部 PLL の選択 → PHY コントロールと終端調整 → LTSSM リンク訓練。

重大なバグ:リンクの不安定さ

起動直後、PCIe リンクが正常に立ち上がってもすぐに切断(Recovery)し、最終的にはダウンしました。

  • 現象: STM32 側が不要にリンクを切断。RX レーンは正常だが、TX レーンのアイパターンが圧縮され、ジッターにより位相シフトが発生。
  • 原因特定: COMBOPHY 内の SERDES PLL が断続的にロックを失い、VCO がジャンプしてデータ送信が破綻していることが判明。
  • 解決策: RCC の 25 MHz クロックではなく、ボード上の専用 100 MHz クリスタルオシレーターを参照クロックとして使用。これで安定動作(Gen1 x1 2.5 GT/s)に到達。

8. バグの究明:RISAF とセキュリティリスク

列挙時の不具合

PCIe デバイスへの読み書きを試みると、ファームウェア側ではすべてのデータが「0」に戻ってくる現象が発生しました。

  • 現象: 書き込み TLP は正常に送信されるが、デバイス側で応答するデータは全ゼロ。読み取りも同様に全ゼロが返ってくる。

原因:RISAF (Resource Isolation Slave Unit) のバグ

ST リファレンスマニュアルに記載の Address Space Protection, Full (RISAF) という機能の誤動作でした。

  • RISAF は、セキュアでない領域からのリソースアクセスをブロックするメカニズム。
  • しかし、攻撃者が 32 ビット単位の読み書きトランザクションを実行した場合:
    • 読み取り: リクエストは通るが、返されるデータは常に
      0x00
      に置換される。
    • 書き込み: データに関わらず、TLP はゼロで送信され、MMIO レジスタを上書きする。
  • 検出遅れ: 障害中断(Fault Interrupt)が生成されるのは、書き込みがディスパッチされた後であるため、即座に防御できない状態を作る。

セキュリティリスクと報告

これはシリコン上のバグであり、特定の展開ケース(PCIe ペリフェラル + TrustZone モニターの組み合わせ)において権限昇格やサイドチャネル攻撃の温床となり得る可能性があります。

  • 対応: STMicroelectronics 社へ PSIRT 経由でアドバイザリー提出。
  • 結果: バグが確認され、エラッタ 2.3.33として公式に公開済み。

9. パフォーマンスベンチマーク (PIO モード)

FMC を使用した既存システムと比較した PCIe の透過率:

  • ソフトウェア
    memcpy
    性能
    : 約 1.77 Gbps(理論最大 4 Gbps の約 44%)。
    • ストリップ命令で TLP(36 バイト) 生成。ヘッダーの影響により効率化に課題あり。
  • DMA 使用時の潜在性能:
    • TLP サイズを拡大し、有効データ比率を 92.75% に向上。
    • 理論ピーク速度は約 3.71 Gbps 可能。

これにより、FMC (977 Mbps) の約 3.8 倍という画期的な性能向上を実現しました。

10. 今後の展望と結論

  • FPGA 連携: Artix-7 FPGA での自家製 PCIe スタックテストおよび Efinix Ti375 ボードによる実装を計画。
  • 脆弱性のさらなる調査: RISAF を経由してバックアップ SRAM などへ
    0x00
    を書き込む等の権限昇格 exploit の可能性を確認中。
  • 結論: 「理想的な MCU」を探求する旅は続きますが、今回は複雑な SoC の起動技術と PCIe/FPGA 接続のノウハウ、そして重大なバグ報告という成果を収めました。

※コードはすべて GitHub に公開しております。詳細はそちらをご覧ください。

同じ日のほかのニュース

一覧に戻る →

2026/11/09 4:08

Dux:ファイルマネージャーとテーマ機能を備えた、無料のオープンソース Wayland デスクトップシェル

## Japanese Translation: DMS 2.1 の最新リリース(コードネーム「Stormborn」)は、無料のオープンソースデスクトップ環境に大規模なアップグレードをもたらします。その統一されたビジュアル体験と強力な新機能により、アップデートの中心には Dux Modular Shell という動的デスクトップインターフェースがあります。このシェルはスムーズなアニメーション、ライトモードとダークモード間のシームレスな切り替え、および対応する GTK、GTK4 および Qt アプリケーション向けの一致した色の自動生成をサポートします。このバージョンでは高度なユーティリティも統合されており、其中包括 Dux Files — タブ、分割ビュー、検索、ゴミ箱、デバイス、ネットワーク共有を備えた高速でキーボードファーストのファイルマネージャー — と Dux GOP です。Dux GOP は CPU、メモリ、GPU、ディスク、ネットワークインターフェースなどのシステムメトリクスに対するステートレスなモニタリングを提供します。追加機能にはビデオウォールペーパー、改修されたメディアプレーヤー、インターフェースの密度調整、そしてライトおよびダークテーマの両方でターミナルの色とシンタックスハイライトを最適化する専門的な「dank16」アルゴリズムが含まれます。リリースでは、美しくデザインされたログイン体験を提供する Dux Greeter、超高速ファイルシステム検索ツールである Dux Search、Google、Microsoft、CalDAV、iCloud プロトコルを深く統合したクラウド連携機能を備えた Dux Calendar も導入されます。目立つ機能として、すべてのアプリケーションに単一のテーマを適用でき、手動設定なしで一貫した美的体験を実現できる点が挙げられます。「支払額自由」モデルを採用しており、開発インフラストラクチャの資金調達のために自主的なチップに依存しながらも、誰もがアクセスできるようにしています。高性能とモダンなデザインの組み合わせにより、DMS 2.1 はアクティブなコントリビューターコミュニティによって完全に牽引される統合的で高効率なデジタルワークスペースをユーザーに提供します。

2026/11/05 2:05

宣言的ドラッグ&ドロップ

## Japanese Translation: 元の要約は内容が充実していますが、Key Points List(特に引用および具体的なデモ例)に含まれる詳細な情報が不足しているため、完全性を保ちながら文の流れを維持しつつこれらの情報を統合した改良版を提示します。 以下に、主要な点をすべて取り入れた**改良された要約**を示します。 > Horowitz, Blinn, および Heer による論文「Declarative Dragging」は、UIST 2026 で最優秀論文賞を受賞しました。Andrew Horowitz が 2022 年に発表した数学を実感化するためのゲームプロトタイプに着想を得たこの研究は、2023 年シアトルで行われた著者間の議論を経て発展しました。本システムでは、「Declarative Dragging」(D2)というモデル駆動型アプローチによりドラッグアンドドロップのインタラクションを再定義しており、幾何学を手動で計算するのではなく未来の状態を定義します。**Dragology**ライブラリを SVG インターフェースの実装に用いた D2 は、**speculative rendering** を採用してインタラクションを瞬時にプレビューし、重労働なく滑らかなアニメーションを合成します。このフレームワークは非常に組み合わせやすく、スナップやフローティング、トランジションといったモディファイアを組み合わせて単純な動作と統合することができます。本アプローチは、代数やねじれた木、ベジェ曲線、編み目、カードの山、顔(face)、トロミノ、芽生える木などの教育用デモを含む幅広いアプリケーションを可能にします。注目すべき学術的な拡張には、並列データを同時に操作する**「Permutation lab」**と、宣言的なドラッグによってコードのリファクタリングを実感化・発見可能にする**「Hazel」**環境があります。今後の取り組みとしては、ゲームパッド制御への適応や、元の数学ゲームを 2D スクリーンから完全に機能する 3D ワールドへと移行することが挙げられます。

2026/11/09 3:16

ゴールドマンサックスが銀行家やトレーダーからClaude Codeの使用を取り下げる

ゴールドマン・サックスは、エンジニアに対し、Anthropic の Claude などのサードパーティ製の自律型 AI コーディングエージェントを用いて生産環境向けのソフトウェアを開発することを大幅に制限し、実質的にトレーダーや銀行家らが市場モデルや顧客分析のためにそれらを使用するのを禁じています。同社は全従業員向けに内部の AI アシスタントを維持しており、公式なエンジニアリング監査が欠落する外部エージェントの使用を停止しましたが、これは以前「vibe coding」として非エンジニアが最小限の監督下でツールを開発することを推奨していたガイダンスからの変更です。この方針転換は、検証されないコードがテストおよびレビュー統制を回避すること、顧客データに関する情報障壁違反、およびトークン単位で課金される生産性コスト(Accenture が現在は従業員 1 人当たり月々 29 ドルを負担して Claude を導入)への懸念に由来します。これはゴールドマンが以前トレーダー向けに同様のツールを推進したにもかかわらず、Anthropic のエンジニアと協力してバックオフィスのワークフロー向けのエージェントを開発していたことからの顕著な変化を示しています。この制限措置にもかかわらず、ゴールドマンは Anthropic の upcoming Nasdaq 上場において主要な引受業者として残っています。また、労働力削減を進めつつも Claude Code の大規模導入を計画するバークレイズなどの競合他社との対比も示されています。

STM32MP2 を遊びながら学ぶ | そっか~ニュース