0824 | Qwen 3.8 27B、30分でリバースエンジニアリング、JITコンパイル5μs、Android車載マルウェア、Wi-Fi 8

葵: Bri Radioの「HackerNews Daily」、葵です。今日は、AIにリバースエンジニアリングを任せて30分で完了させた話や、Rustで作る高速JITコンパイラ、Android車載システムに感染したマルウェアなど、注目のトピックを取り上げます。

悠真: 悠真です。ほかにも、速度を追わないというワイファイ8の話や、アスロンの終焉、シドニーマラソンのメダルに描かれた意外なスタジアムなど、多彩な話題が並んでいます。さっそく始めましょう。

葵: Hacker Newsのとある投稿で、Qwen 3.8 27Bというオープンモデルにリバースエンジニアリングの仕事を任せたら、30分で完了したという話が注目を集めています。XDAが紹介したこの実験は、フロンティアモデルではなく一般に入手できるモデルで、かなり複雑な作業をこなした点が話題の中心です。

悠真: 一方で、実際のハードウェアでの実行環境に興味を持つ声もあります。あるコメントでは、デュアルのArc Pro B70構成で毎秒およそ22トークンの処理速度が得られていると報告されていて、速くはないが悪くもなく、むしろ量子化の度合いが低い分だけ健全だという評価でした。モデルの性能だけでなく、手持ちのマシンでどのくらい動くかという実用面に、このスレッドの関心は集まっているようです。

悠真: malisper氏の記事は、Rustでコピー・アンド・パッチ方式のJITコンパイラを組んで、ARM64のマシンコードを生成し、インタプリタや手書き実装に対してベンチマークを取った内容です。歴史的に高速なJITコンパイルは黒魔術扱いで、アセンブリの知識が必要だったとこの記事は指摘していますが、今はAIの助けで、アセンブリを直接ターゲットにする短いコンパイル時間のJITを書くのが以前よりずっと簡単になったと言っています。

悠真: 中心になっている開発がpgrustです。著者は最初、JITコンパイラの実装は非常に難しいと思っていたんですが、AI支援のおかげで予想よりはるかに簡単だった。これがpgrustの高速性の理由の一部だと説明しています。pgrustのJITはだいたい5マイクロ秒でコードをコンパイルして、しかも一部のサブセットではなく、すべてのSQLクエリをJITコンパイルできるようにしていると記事は述べています。JITはうまく機能すると2倍から5倍、場合によってはそれ以上の性能向上を生むことがあり、主な用途は実行時に得た情報がプログラムの動作を大きく変えるケースです。

悠真: 記事では具体例として、リテラル文字列と繰り返しだけをサポートする単純な正規表現エンジンの実装を示しています。パーサは省いて、解析済みのRust構造をそのまま使う形です。ノードはリテラル文字列、連結、繰り返しの3種類だけで、代替、つまりalternationや先読みはサポートしない設計になっています。

葵: ただ、Hacker Newsの議論では賛否が分かれていましたね。glenjamin氏は、pgrustは興味深いものの、大幅な変更を伴うから上流に統合する実行可能な道筋がなく、最終目標が十分に堅牢になって広く採用されることなのかと問いかけています。これに対してFiberBundle氏は、本当に興味深いか疑問だとして、本質的にはこういう作業に不適格な人々によるバイブ・コーディング、つまり雰囲気だけで書くコーディングにすぎないと切り返しました。著者の一人は大規模Postgresクラスタでの勤務経験を資格として主張したけれど、実際にはデータベースでもコンパイラでも働いたことがない、という指摘です。

悠真: セキュリティの面でも議論がありました。roschdal氏がJITコンパイルは安全ではないと述べたのに対し、dennis16384氏は、ClickHouseでは長年にわたりJITが中核にあるが、十分に安全だと思うかと質問しています。sebzim4500氏は、そうかもしれないけれど、データベースインスタンスのすべてのユーザーを信頼できるユーザーもいるだろうと応じました。さらにasdfsa32氏は、JITはW^X、つまり書き込みと実行を排他にするセキュリティポリシーに違反することを要求するため、システムのロックダウンと保護を制限し、システム全体への影響があると指摘しています。これがiOSでJITがApple同梱ソフトウェアに限定されている理由だというのが、その主張です。

葵: そのW^Xの点には反論も出ています。shakna氏は、Wikipediaのページによれば、書き込んだ後に実行へ切り替えるだけなので、これは小さな問題にすぎないと返しました。さらにcodethief氏は、GrapheneOSもJIT利用を大幅に制限していて、Android RuntimeのJITコンパイルとプロファイリングは完全に無効化され、フルAOT、つまり事前コンパイルに置き換えられている。基本OS内の唯一のJITはVanadiumブラウザのV8だけだとも述べています。genxy氏が、彼らはコーディングの運転免許を失うだろうとコメントしたのも、この流れのなかで印象に残りますね。

悠真: カスペルスキーのSecurelistが、Android搭載の車載ヘッドユニットのファームウェアに感染するマルウェアを報告しています。この話題について、Hacker Newsでも議論が起こっていますね。

葵: ええ。一般的なAndroidマルウェアによる感染で、攻撃者が何を狙うのかという議論があります。ヘッドユニットそのものには、攻撃者にとって価値のあるデータはほとんどないため、感染したデバイスをボットネットに組み込むことが、もっとも考えやすいシナリオの一つだとされています。

悠真: でも、現実にはヘッドユニットをスマートフォンとペアリングして使う人が多いですよね。Hacker Newsのコメントでは、Retr0idさんが、こうしたマルウェアの将来バージョンが、横方向に伝播していく可能性を指摘しています。つまり、車載ユニットだけにとどまらず、接続されたスマートフォンへと感染が広がり得るというわけです。

葵: なるほど。つまり現時点での報告では、ヘッドユニット自体をボットネットに加える攻撃が想定されているものの、実際にスマートフォンへの横展開が起きているかどうかは、まだ検証されていない、未知の領域だということですね。

悠真: 話題を変えて、Wi-Fi 8 を見てみましょう。これは、何年かぶりに速度を追わない初めての無線アップグレードとして紹介されています。従来の規格が帯域幅の数字を高める方向に進んできたのに対し、今回の焦点は別のところに置かれています。

葵: その背景には、多くのネットワークがそもそも高速回線に接続していない現状があります。ある利用者は、自分の地域で利用できる最大速度が毎秒150メガバイト程度で、毎秒5ギガや6ギガなどは十分すぎる上限だと話しています。一方で、届く範囲と混雑は実際に問題になってきたと指摘しています。

悠真: なるほど。つまり通信速度の頭打ちよりも、家の中の電波の届き方や、周辺機器が増えたことによる混雑のほうが体感として効いてくる。Wi-Fi 8 が具体的にその混雑やカバレッジの問題をどう扱おうとしているのかが、この記事の論点になっているようです。

葵: OS/2 Museumブログが「The End of an Athlon」という記事を公開していて、特定のAMD Athlonシステムがもう復活できない理由を扱っています。問題は配線自体にあり、接続が一度壊れたら修復する現実的な道はありません。

悠真: うーんそれをHacker Newsの議論が引き継いでいて、お金が無制限にあって買い直すより修理したい場合、これは直せるのかという質問が出ています。回答は明確で、無制限の資金と超先進的な未来技術が必要だと。配線を整列させて再接続する手段が事実上ない、と。

葵: つまり単にお金の問題ではなく、今の技術では物理的に不可能な話なんですね。システム内部で断線した接続を元に戻す手段がなく、実際には買い直す以外に選択肢がないという結論になります。

葵: シドニーマラソンの完走メダルに、世界に七つあるアリアンツ・スタジアムのうちの一つを誤って描いてしまったという話題です。実際に描かれていたのは、ミュンヘンのスタジアムだったとのこと。

悠真: デザインを考えていた段階では、八つ目が存在していたかもしれません。というのも、ブラジルのパルメイラスのスタジアムがかつてアリアンツの命名権契約を結んでいたものの、その契約が更新されなかったため、現在はヌバンク・パルケという名称になっているからです。つまり、デザイン作業が進んでいた時点ではアリアンツを名乗る選択肢が八つあり、どの建物を選んだのかを取り違えてしまったというのが、このミスの背景にあるようです。

葵: 今日のエピソードでは、Qwen 3.8 27Bがたった三十分でリバースエンジニアリングの仕事を終えた話と、五マイクロ秒でコードをJITコンパイルする記事、そしてpgrustが将来的に本流へ採用されるかどうかという開かれた問いを扱いました。

悠真: そうですね。私としては、この二つの話題が面白く交差しているように感じました。ハーネスの詳細を求めるコメントが付いたそのインパクトのある成績と、AI支援でここまでJITコンパイルの敷居が下がったという話は、すごく考えさせられました。

葵: 確かに。AIがアセンブリを直接ターゲットにする道を開いてくれた今、コンパイル時間の短い独自JITを持つデータベースがいつか現れるのか、引き続き注目していきたいところです。お聞きいただき、ありがとうございました。