GhostWrite アタックについて説明されているファジングの論文、RISCVuzzの論文を読んでいこうと思う。 ghostwriteattack.com RISCVuzzのフレームワークについて。 テストを制御するサーバ & クライアント (RISC-V CPU) クライアントはネットワーク経由で命令シーケンスと入力を受け取り、その結果の状態を返す クライアントについて。 C言語とRISC-Vアセンブリの混合で実装されており、テストケース毎にレジスタを設定する。 テストケースを実行し、結果をサーバに報告する。 クライアントがセグメンテーションフォルトを検出すると、フォルトが発生したページとそれに続く2つのページをマッピングして、コーナーケースを処理する。 クライアントのノイズ除去について、以下の方針を取る。 すべてstatic library link を行い、各環境で動作が異なること

前回のブログではBinary Translation型のエミュレータの実装において、いくつかの命令を新しいTCG形式に書き直した。これをすべてのメモリアクセス命令について修正していこうと思う。RISC-Vには以下のロードストア命令が定義されている。 命令 アセンブリ言語 説明 LD ld rd, imm(rs1) 64ビットデータロード LW lw rd, imm(rs1) 32ビット符号拡張付きデータロード LWU lwu rd, imm(rs1) 32ビット符号拡張無しデータロード LH lh rd, imm(rs1) 16ビット符号拡張付きデータロード LHU lhu rd, imm(rs1) 16ビット符号拡張無しデータロード LB lb rd, imm(rs1) 8ビット符号拡張付きデータロード LBU lbu rd, imm(rs1) 8ビット符号拡張無しデータロード SD s

GhostWrite アタックについて説明されているファジングの論文、RISCVuzzの論文を読んでいこうと思う。 ghostwriteattack.com ソースコードやエミュレータを必要としないハードウェアCPUの脆弱性を検出するフレームワーク「RISCVuzz」を開発した。 基本的な考え方は、作動CPUファジング・アプローチを用いること。5つのConsumer GradeなRISC-V CPUを用いて評価を行い、3つの深刻なセキュリティ脆弱性を特定したということになっている。 GhostWrite : 攻撃者が制御するバイトを、攻撃者が選択した物理メモリ位置に書き込む非特権命令シーケンス halt-and-catch-fire : 回復不能なCPUの停止をもたらすシーケンス 評価対象のハードウェア： THead XuanTie C906 THead XuanTie C908 THea

GhostWrite アタックについて説明されているファジングの論文、RISCVuzzの論文を読んでいこうと思う。 ghostwriteattack.com msyksphinz.hatenablog.com msyksphinz.hatenablog.com msyksphinz.hatenablog.com もう一つの脆弱性、CPUを完全に停止させてしまうベンダ拡張命令について見ていく。 以下が問題を再現させるアセンブリコードである： C906 : th.lbib命令の定義について確認しよう。 th.lbib t0, (t0), 0, 0 frcsr t0 li t0, 0 th.lbib は以下に命令仕様が置かれている： https://github.com/XUANTIE-RV/openc906/blob/main/doc/%E7%8E%84%E9%93%81C906%E7%94%

自作RISC-Vアウトオブオーダコアの実装、FPUを実装している。 基本的な演算について、FPNewとの接続作業は完了した。演算自体は上手く回ってFPレジスタに答えを書くことが出来ているようだが、問題はFFLAGSをアップデートするパスを用意していなかった。この実装方法について考える。 FFLAGSはシステムレジスタとして定義されており、以下のビットフィールドを持つ。 FFLAGSレジスタは演算命令によってまい命令アップデートされるため、汎用レジスタと同様に扱う必要がある。つまり、アウトオブオーダ実行を行ったとしても正しくフラグの結果を更新する必要があり、FPレジスタと同様にリネームのような処理が必要となる。 したがって、いくつかの実装方法がありそうだ。 ROBの命令エントリ毎にFFLAGSの結果を保持しておき、コミット時にFFLAGSシステムレジスタを更新する。 FPR書き込みレジスタと

勉強のためにOpenXiangShanのドキュメントを読む。原文は中国語なので、翻訳しながらまとめていく。 xiangshan-doc.readthedocs.io XiangShanとは Chiselで開発されたオープンソースのRISC-Vプロセッサ。ロードマップは以下の通り。 2021年7月 雁栖湖アーキテクチャ。RV64GC, 28nmプロセスで1.3GHz 2022年3月 南湖アーキテクチャ。RV64GCBK, 14nmプロセスで2.0GHzを目標 昆明湖アーキテクチャ。現在進行中。 CPUパイプラインのフロントエンド、バックエンド、メモリアクセスパイプライン、L1キャッシュ、L2/L3キャッシュなどがすべて研究室のチームによって実装されている。 XiangShanプロセッサのフロントエンドは6命令発行で設計されている。 フロントエンド 分岐予測ユニット 命令フェッチユニット 命令

きっかけは、RISC-Vのベクトル命令一覧で、viota.m命令が存在していることからだった。 命令の説明文によると、 The viota.m instruction reads a source vector mask register and writes to each element of the destination vector register group the sum of all the bits of elements in the mask register whose index is less than the element, e.g., a parallel pre x sum of the mask values. viota.m命令は、ソースベクトルマスクレジスタを読み出し、その要素のインデックスが小さい要素の全ビットの合計を、書き込みベクトルレジスタ

RISC-VのPrivileged仕様Version 1.12 ではCMO命令群(Cache Management Operation)についての仕様が検討されている。 これについて調査してみよう。 仕様書は以下に置いてある。誰でもダウンロードできる。 github.com キャッシュ操作命令については以下の3種類に大きく分けることができる。 管理(management)命令 (Zicbom) : キャッシュされたデータに対する操作を行う。 ゼロ(zeros)命令 (Zicboz) : メモリ位置に対してゼロ埋めを行う。 プリフェッチ命令 (Zicbop) : プリフェッチを行う。 管理(management)命令 ちなみに、以下のClean, Flush, Inval操作の定義は以下のようになっている。 Invalidate, 無効化：は、キャッシュブロックのコピーの割り当てを解除する。

RISC-VのPrivileged仕様Version 1.12 ではePMPレジスタ群(PMP Enhancements)についての仕様が検討されている。 これについて調査してみよう。 仕様書は以下に置いてある。誰でもダウンロードできる。 https://raw.githubusercontent.com/riscv/riscv-tee/main/Smepmp/Smepmp.pdf そもそものモチベーションは、現状のPMPはスーパバイザモードについてのみ適用されており、マシンモードでは適用することが出来ない。これではマシンモードと非特権モードを使った攻撃を防ぐことが出来ない。 現在のスーパバイザモードを使った攻撃手法として以下が紹介されている： SMAP(Supervisor memory Access Prevention) : 特定のコードパスをたどらない限り、OSが非特権プロセスのメ

QEMUのTCG Block Chainingを実装したので、次はもう一つの障害、TB Lookup and Jumpを実装しよう。TB Lookup and Jumpは、TCG Block Chainingではカバーしきれない部分を最適化するものだ。TCG Block Chainingは、あるブロックからあるブロックへ、毎回必ず何度でも同じようにジャンプすることが求められるものだ。つまり、Jump Register命令のようにレジスタの値によってジャンプ先が変わる場合にはこの技術は使えない。ダイレクトジャンプを使用しているからだ。 一方で、TB Lookup and Jumpは、まずはレジスタジャンプを行うレジスタ値をTCGの先頭アドレスをキーにしたLookup Tableで検索し、見つかればその物理アドレスを返すことですぐにジャンプする。これは一度ホストのアセンブリ命令実行状態から制御

ET&IoT 2020は今年はコロナウイルスの影響でデジタル開催されています。カンファレンスプログラムについては、全て動画にて公開されています。 今年も私は「ますます注目されるオープンソース命令セットアーキテクチャRISC-Vの最新動向」(実は前回とタイトルが一緒！)という題目で発表させて頂きました。 発表と言っても、動画を取ってアップロードしているので、指定日になると公開されるだけです。指定日は11/30(月)、つまり今日。たぶん公開されているはずだ... www.jasa.or.jp 動画の内容は30分で、私が地声で収録しています。しかもiPhoneのイヤホン(大昔に使っていたiPhoneのイヤホン)を使って収録しているので音質も良くありません。こういうのが初めてだったので、ちょっと試行錯誤してしまいました。 ちなみにPowerPointには「1ページ単位で音声を吹き込み、さらにそれを

自作CPUにおいてデバッグモニタというのは常に重要な機能で、私は特に波形を見るのがとても嫌いなのでデバッグ情報はなるべくテキスト形式で出力している。ちなみ今回のデバッグ機能というのはいわゆるJTAGのようなデバッグ機能ではなく、CPUをデバッグするための実装者向けデバッグ機能だ。 昔私の作った自作CPUでは、コアのパイプラインの流れが監視できるようにデバッグモニタを用意しており、デバッグビルド時にこのポートを生やして情報を出力していた。 /* Debug-Port */ io.dbg_monitor.hart_id := hart_id.U io.dbg_monitor.inst_fetch_req := io.inst_bus.req io.dbg_monitor.inst_fetch_addr := io.inst_bus.addr io.dbg_monitor.inst_fetch_

前回の続き。いろいろバグを潰しながら、メモリマップを変えつつバイナリを用意して、ついにDhrystoneを最後まで完走させることができた。さて問題の実行速度だが、Dhrystoneで測定してみることにする。比較対象はQEMU、自作RISC-Vエミュレータ、そしてSpikeだ。実行結果は以下のようになった。 Simulator Dhyrstone Time[s] QEMU-5.1.0 0.789 Dydra-6ec3e02 5.4504 Spike 28.909 注：Dydraが自作のBinary Translation型RISC-Vエミュレータ とりあえずQEMUが爆速なのは理解できた。かなり大きな差を開けれらているなあ... Rustのパフォーマンス解析ツールを使用しようとしたが、flamegraphはWSLに対応していないので上手く動作しなかった。AWS上に普通のLinuxマシンを用意

Rustで作っているBinary Translation型のRISC-Vエミュレータ、Dhrystoneを使ってシミュレーション速度の解析を行っている。前回の解析でFNVHashMapを使うことである程度速度の向上が見られたが、より性能を上げるためにはそもそもHashMapを使わなければよいのではないかという気分になってきた。HashMapはinsertしたキーを必ず保持するようだが、必ず保持しておく必要はなく、キャッシュのように動いてくれるだけで十分だ。ダイレクトマップのようにアドレスに関連ついてTCGを保持しておき、同じキーによりDropoutしてしまっても、もう一度変換すればよいだけの話だ。というわけで、HashMapをあきらめて単純なダイレクトマップキャッシュ（というか配列）に置き換えてみることにした。 キャッシュとして1024要素を保持できる配列を用意し、 m_tb_text_h

自作Binary Translation型RISC-Vエミュレータで性能向上を図っているが、どうにも上手く行かない。いろんな方法を試行しているのだが、いくつかの試行についてメモをしておこうと思う。 即値生成をEAX以外でもできるようにする 即値生成はEAXに対してのみできるのかと思っていたが、実はそうでもなかった。32ビットまでの値であればEAX以外のレジスタに対しても即値を生成できる。これまでは32ビットの即値生成に対して、 MOV $imm, rax MOV rax, target_x86reg という2段階で生成していたが、これは実は1命令に省略できるということを知った。まあこれも考えてみれば当たり前の話ではあるが、どういう事情でRAXにレジスタを制限してしまったのかは忘れてしまった。たぶん誤った資料を見たか、勘違いした。 冗長なレジスタ読み込みと書き込みを省略 例えば以下の加算命令

前回の続き。自作Binary Translation型RISC-Vエミュレータの最適化作業、いくつか改善を取り入れたのでflamegraphを用いて最適化の結果を解析する。現状の実装でflamegraphを適用した結果が以下となった。 これをよく見てみると、clone()が多く出てきていることが分かる。これはもしかしてCloneトレイトにより大量にオブジェクトのコピーが発生してしまっているということか？確かに、TCGの生成においてはかなり大量にCopyやらCloneを使ってしまっている。これを削減する必要があるということだろうか。 試しに、これまですべてのインスタンスをCopyで繋げていたものを、ポインタで繋げ直すとどのようになるのだろう？Rustでポインタを扱うのが非常に面倒なので、Rc<RefCell<>>を使って一気に書き直してみることにした。 例えば、今までこのように実装していたも

自作RISC-Vエミュレータの性能解析続き。私はWSL1を使用しているので、Rustの性能解析ツールflamegraphを使用することができない（どうもLinuxのツールが必要で、これがWSL1では使用できないようだ）。 qiita.com AWS上に急遽Rustの環境を構築し、そこでflamegraphによる性能解析を行った。Dhrystoneを実行し、flamegraphによる性能解析を実行した。 $ cargo flamegraph --bin dydra -- --machine sifive_u --elf-file /home/msyksphinz/work/riscv/freedom-e-sdk/software/dhrystone/release/dhrystone.elf これ取得したflamegraphが以下である。...なんかHashMapの処理がほとんどだな...R

結論から言うとモデルを作っているのだけれども、例えばRISC-VのMULH命令などの計算結果の上位ビットを持ってくるようなタイプの命令は、最初に何が正しいのかナイーブな方法で計算しておかないと訳が分からなくなる。 一つのステップは、riscv-isa-sim (Spike) が完全であるとまず信用すること。自分のハードウェアとSpikeが完全に同じ答えを返すように作り込むのが大前提。 それでもってSpikeとハードウェアの答えが不一致となった場合にどうするのか、という問題だが、MULH命令の答えが合わない場合は上位64ビットしか出てこないのでデバッグが地獄になってしまう。 そこで、64ビット×64ビット=128の答えを計算するモデルを作っておき、ハードウェアがどういう動作をすべきなのか、比較できるようにしておく。 ここでそのためのモデルはC++を使って記述している(多分PythonとかRu

T-Headが提案しているRISC-VのMatrix Extensionについて、マニュアルを読みながら理解していこうと思う。 とりあえずマニュアルで、どのようなレジスタが存在しているのかを理解していく。プログラミングモデルとサンプルコードも読み進めていきたい。 github.com 命令仕様 行列乗算命令 行列乗算命令は、ms1とms2で指定された行列レジスタから行列A（sizeM×sizeK）と行列B（sizeN×sizeK）を取り出し、mdレジスタから$A[M][K]\times(B[N][K])T$の乗算結果を行列C（sizeM×sizeN）に累積し、出力は累積レジスタを上書きされる。 行列Aの形状：M行(sizeM)、K列(sizeK/要素サイズ(バイト)) 行列Bの形状: N行(sizeN), K列(sizeK/要素サイズ(バイト)) 行列Cの形状: M行(sizeM), N列

RISC-Vには64bitの乗算など、通常の計算の範囲では追いつけないような演算も含まれている。 例えば、MUL命令やMULHSU命令などは、64bitのデータ同士の演算であり、MULHは演算結果の128bitのうち上位の64bitを返してきたりする。 これらの演算をサポートするためには、GNUの多倍長演算ライブラリを利用すればよい。自作ISSでは、GMPを使っている。 msyksphinz.hatenablog.com GMPを用いることで64bit同士の乗算でも、問題なく実行できるようになっているのだが、いくつかのパタンでうまく実行できない状態が続いていた。 よい機会なので、解析していこう。 GMPにおける符号付整数の演算の考え方 例えば、MUL命令は64bitデータ同士の乗算を行い、結果の下位64bitをレジスタに格納する。 reg[dst] = lower64bit(sign(re