Fadis

Kernel/VM探検隊＠つくば No3 (2026/03/20 11:00〜) @_Alignof の尽力により、一般参加枠を150名まで増枠しました。どうだ参ったか！！！（？） # イベント概要 カーネルやVM、およびその他なんでもIT技術の話題ジャンルについて誰でも何でも発表してワイワイ盛り上がろうという会です。ジャンルの指定は特にありません。楽しければ何でもOK です。詳しい内容や、過去の発表については過去イベントを参照してください。 たとえばLinux・*BSD...

3月20日(金・祝日)、つくばで低レイヤーの祭典 「Kernel/VM探検隊＠つくば No3」が開催されます。ハードウェアからOS、仮想化、コンパイラ、ネットワーク、セキュリティ、コンピュータの幅広い話題で盛り上がって昨日より少しコンピュータと仲良くなりましょう #kernelvm
kernelvm.connpass.com/event/381371/

Linuxカーネルには先日RISC-VでSpectre脆弱性の対策を行うようにするパッチが登場したが、これは「rdtimeを呼ぶと何故か投機的実行が止まる」というドキュメントに書かれていない挙動を利用して実現されていて、早急に標準化された方法が欲しい、という状況らしい

更に発表ではT-HEAD C910でvse128.v命令を使ってページテーブルの権限チェックを迂回して直接物理メモリにデータを書ける脆弱性(GhostWrite)の紹介と、それを使って一般ユーザ権限からrootに昇格するデモを行なっている(これはこの発表以前から知られていた物らしい)。
最後に発表ではOut-of-Order実行するRISC-V CPUにはSpectre脆弱性があり、それを利用した攻撃がささる、というデモを行い、対策が必要であるとしている。ただRISC-Vにはx86_64のLFENCEのような投機的実行を止める目的で用意された命令が無い

その結果、T-HEAD C906、T-HEAD C908、SpacemiT X60でCPUをハングさせる方法が見つかった。C908とX60についてはV拡張の命令を使う為、V拡張を使えなくする事で対策する事ができる。C906はT-HEADのベンダ拡張命令を使うが、この拡張命令は使えなくする仕組みが用意されていない為対策不能とされている

ただT-Headのベンダ拡張命令にデータキャッシュを飛ばす物があり、T-HeadのRISC-V CPUではサイドチャネル攻撃がささる状態になっていた。現在Linuxではrdcycle等の命令をユーザ空間プロセスが呼べないようにする対策が入っている。
規格上未定義の動作となるような命令であっても、それがユーザ空間から実行できてCPUをハングさせるような効果があったらDoS攻撃の手段として使えてしまう。調査では複数のRISC-Vの実装を使ってDifferential Fuzzingを行い、特定の命令で怪しい動きをする実装を探した

ユーザ空間プロセスが任意のタイミングでCPUのキャッシュを飛ばす事ができ、かつ命令の実行にかかった時間を高精度に測る事ができると、別のプロセスが何をキャッシュに載せたかを覗き見できるようになり、サイドチャネル攻撃が可能になる。
RISC-Vではrdcycle等の高精度に命令の実行時間を測れる命令が特に制限なくLinuxのユーザ空間に提供されていた。ユーザ空間からキャッシュを飛ばせるような命令は、fence.iで命令キャッシュを飛ばす事が出来るが、データキャッシュを飛ばす命令は標準のRISC-Vには無かった

Security Researchers Find Current RISC-V CPU Implementations Coming Up Short While many open-source enthusiasts like to flaunt RISC-V as not having the security challenges as x86_64 CPUs have seen over the past several years with various speculative execution / side-channel at...

Security Researchers Find Current RISC-V CPU Implementations Coming Up Short : 実際に市場に出回っているRISC-V CPUの実装に他のアーキテクチャのCPUで見られるような脆弱性が見られるかどうかを調べた、という話。FOSDEM 2026で発表された物らしい
www.phoronix.com/news/RISC-V-...

YouTube video by The Linux Foundation Beyond Zstandard: The Future of Data Compression - Yann Collet, Meta

昨年のOpen Source Summit JAPAN 2025でZstdの作者のYann Collet氏が行ったものらしい。その発表動画がここに上がっている。同氏はMetaで働いていて、Metaでは既にサーバ間のデータの効率の良い受け渡しにOpenZLを活用しているらしい
www.youtube.com/watch?v=PyPV...

OpenZLはSDDLで与えられたファイルの構造に基づいてファイル内に何度も現れる同じ値の構造体や、実はソートされていて差分で記録すると小さくなる数値の列等を高速に見つけ出し、zstdより高い圧縮率での圧縮をzstdより高速に行う。
OpenZLの重要な特徴として、圧縮にはSDDLが必要だが展開には必要ない。またファイルがSDDLに完全に沿っていなくても一応圧縮できる。ファイルフォーマットは物によっては時々アップデートされるが、この仕様により圧縮展開を行うホストに最新のSDDLがデプロイされていなくても正しく圧縮展開ができる

OpenZLではファイルの構造を説明する為のDSLとしてSimple Data Description Language(SDDL)を用いる。SDDLではファイルに並んでいる値に型を付けたり、構造体を定義してデータの階層がわかるようにしたり、同じ型のデータが繰り返し現れる事を示したりできる
openzl.org/sddl/

一方何かを圧縮して通信で送るなりストレージに保存するなりするソフトウェアはしばしば自分が何を圧縮しているのかを知っている。そこでファイルの構造を書いたプロファイルを用意して、それをヒントとして高速に突っ込んだデータの規則性を見つけ出そうというのがOpenZL
openzl.org

可逆圧縮アルゴリズムの基本的な仕組みは、バイト列の中から何度も現れるフレーズや同じ値の繰り返しを見つけて、それらを必要最小限のビット列で表現するという物だが、この時完全に同じではない複数のバイト列の中に規則性を見出す事ができれば、更に攻めた圧縮ができる。
ただ何の手掛かりも無いバイト列の中からこのような完全一致でない規則性を見つけ出すのは高価な計算になりがちで、そうした攻めた圧縮アルゴリズムは実用的な圧縮、展開速度を達成できない事が多い

Format-specific compression with OpenZL : 圧縮対象のファイルフォーマットの情報を使ってZstdを超える「圧縮率」と「圧縮展開の速さ」の両立を目指すオープンソースな圧縮フレームワークOpenZLについて
lwn.net/Articles/105...

おせち

今年の手作りおせち

月見そば

あけましておめでとうございます

どうやらMetaは割り込みに大きな時間を持って行かれてタスクの進みが悪いCPUの影響で関係ないタスクの完了が遅れるのを防ぐ為に、SCX-LAVDの方法でlatency criticalityと判断されたタスクを割り込みによる占有率が低いCPUに逃すという事をやっているらしい

今回Linux Plumbers Conference in Tokyoで出てきたのは、Metaがこのゲームの為に作られたスケジューラを大規模なサーバに応用した、という話。
発表の大部分はSCX-LAVDを複数のCCXに沢山のCPUがぶら下がっている大規模なサーバで動かす際に生じたボトルネックとその対策についてで、そもそも何でそんなスケジューラを選んだのかについてはあまり触れられていないが、その答えが発表資料の補足スライドに書かれている
lpc.events/event/19/con...

そこでSCX-LAVDはタスクの依存関係のグラフを構築し、タスクA->タスクB->タスクCの中間にあるタスクBの平均実行時間が短く、Cが実行されるのは大体Bが原因で、Bが実行されるのは大体Aが原因の時、Bをlatency criticalityの高いタスクとする。
latency criticalityの高いタスクは期限が短くなり、結果他のタスクより優先してCPUが与えられ、実行までのレイテンシが小さくなる。タスクBは実際には既にタスクAにCPUが与えられるまでの時間分待機しているので、これによってバケツリレーのタスクが過剰に待たされる問題が緩和される

この累積的な遅延によって1フレーム内に完了させたい処理が1フレーム内に完了しなくなると、ゲーム画面は瞬間的に固まったり、フレームレートが落ちたりする。プレイヤーはこの時CPU不足と考えるが、実際にはバケツリレーの途中にあるタスクを待たせて後でも良いタスクが走っているだけだったりする。
ゲームのタスクにおけるバケツリレーの待つ側、待たせる側は毎フレームほぼ変化せず、その実行時間も安定している

スケジューラはCPUが空いた時に沢山あるタスクの中から次にCPUに割り当てるタスクを決定する。デッドラインスケジューラではタスクの期限が最も近いタスクを優先的にCPUに割り当てる。I/Oを待っているタスクはI/Oが完了したとしても即座に実行されるわけではなく、スケジューラがCPUを与えるのを待つ。
従って沢山のタスクがデータをバケツリレーしている場合、最初のタスクにデータが与えられてから最後のタスクから結果が出てくるまでの間にこのタスクのセットは何度もスケジューラでCPUを与えられるのを待つ事になる

その結果ビデオゲームのタスクはその多くが長時間生存する、数十の極めて頻繁にスケジュールされるタスクが殆どのCPU時間を使う、1回のタスクの実行時間は100usオーダーで安定して非常に短いがそれが周期的にスケジュールされる、殆どのタスクはI/Oやロックを待っている、といった傾向が見られた。
これは、沢山のタスクが他のタスクの出力を受け取って、それに対して何らかの軽い処理をして次のタスクに結果を渡すというバケツリレーをしている事、それが1フレームのレンダリングを行う度に繰り返し行われている事を示唆していた

Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming Changwoo Min with Igalia presented yesterday at Open-Source Summit North America on optimizing the kernel's scheduler for Linux gaming

2024年のOpen Source Summit North AmericaでIgaliaの人が発表したのはSCX-LAVDと呼ばれる新しいLinuxのスケジューリングアルゴリズムだった。このスケジューラはSteamDeckで実行されるゲームのユーザ体験レベルでのパフォーマンスを改善する為に作られた。
www.phoronix.com/news/LAVD-Sc...
このDomain specificなスケジューラを開発する為にIgaliaは多くのビデオゲームに共通するワークロードの傾向を調べた

Meta Is Using The Linux Scheduler Designed For Valve's Steam Deck On Its Servers An interesting anecdote from this month's Linux Plumbers Conference in Tokyo is that Meta (Facebook) is using the Linux scheduler originally designed for the needs of Valve's Steam Deck..

Meta Is Using The Linux Scheduler Designed For Valve's Steam Deck On Its Servers : Meta(Facebook)がサーバのスケジューラにSCX-LAVDを使っているという話。SCX-LAVDはSteamDeckで快適にゲームを動かす為に作られたLinuxのスケジューラ
www.phoronix.com/news/Meta-SC...

Gentoo Linux on ASUS Chromebook CM30

Linuxオタク( @fadis0.bsky.social )が「Chromebookだけでも割と何でも出来るからなぁ」と言っている時のASUS Chromebook CM30

パウンドケーキ型で焼いたチーズケーキ

今年のクリスマスケーキはチーズケーキを焼いてみた。砂糖100g、クリームチーズ200g、レモン汁30ml、薄力粉25g、たまご1こ、生クリーム200mlをフードプロセッサーで混ぜ、型に流して170度のオーブンで45分間焼く

YouTube video by Kui Wu [Siggraph Asia 2025] Auto Hair Card Extraction for Smooth Hair with Differentiable Rendering

ヘアカードを計算で生成する手法としては既にUnreal Engineによる実装が存在するが、実験ではUnreal Engineの実装より格段にStrand Basedに近いレンダリング結果が得られるヘアカードが生成されている。この実験結果はいい感じの比較動画が上がっている
www.youtube.com/watch?v=H6tn...

このレンダリング結果が元の髪をStrand Basedでレンダリングした結果に近くなるように微分可能レンダリングでパラメータの最適化を行う。最後に頂点に記録されたパラメータをカードに投影してテクスチャに焼く事でエイリアスの問題を回避する。
最後にほぼほぼそれっぽい状態になったヘアカードに対して、髪の毛が根本以外の部分で頭にめり込んでいるようなおかしな状態を修正する為にテクスチャの値とカードの位置、向き双方をパラメータとした微分可能レンダリングを行う

髪の毛は細い為テクスチャのテクセルを1テクセル未満の幅でカバーする事になる。テクスチャの値を誤差逆伝播で修正しようとすると勾配にエイリアスに起因するノイズが乗って最適化が上手く機能しない。
そこでこの手法ではテクスチャに書く値を直接最適化の対象にするのではなく、Strand Basedの髪の毛を一旦カードの表面に投影し、テクスチャに書く予定の深度等のパラメータに基づいて投影した髪の毛を変化させた結果をStrand Basedでレンダリングする。パラメータは髪の毛の頂点に持たせる

Bishop formulasは毛の根本での法線の向きを決めるとそこから毛先に向かって連続的に変化する法線を生成するので、根本での法線を決める必要がある。そこで束を構成する毛をヘアカードの表面に投影し、投影された毛と元の毛の差が最小になるような法線の向きを探す。
この過程は微分可能ではないが探索空間は小さいので力技で最適化を行う。ヘアカードの位置と向きが決まったらカードに貼り付けるテクスチャのパラメータを決める。これはStrand Basedのレンダリング結果とヘアカードのレンダリング結果が近くなるように微分可能レンダリングを使って求める

次にグループ内の髪の座標の平均を通る曲面を作りヘアカードとする。曲線からは曲面の接線しか定まらない為法線が必要になる。そこでDiscrete elastic rodsのBishop formulasを使って法線を決める
dl.acm.org/doi/10.1145/...